Archive for June 27, 2017

Tuesday, June 27, 2017

Little Snitch 4 Public Beta

Objective Development (Hacker News):

Third party developers can now bundle their apps with an Internet Access Policy file containing descriptions of all network connections that are possibly triggered by their app. Little Snitch will then display that information to users, helping them in their decision how to handle a particular connection. A description of the policy file format will be provided soon.


The network filter now performs Deep Packet Inspection instead of the previous IP address based filtering. This results in much more precise filter matching, especially in those cases where one and the same IP address is possibly associated with multiple hostnames (e.g. vs.


The code signature of the connecting processes is now taken into account. If a rule was created for a process with a valid code signature, that rule will no longer match if the signature changes or becomes invalid. This prevents malicious software from hijacking existing rules.


To avoid a vast numbers of connection alerts from appearing when using common macOS and iCloud services, Little Snitch now provides preconfigured rulesets for these usage areas.

Sounds awesome. It is compatible with macOS 10.13 if you use the new option in System Preferences to allow the kernel extension to load. Previously, kernel extensions just had to be signed using a special key that you apply for. Going forward, Apple is deprecating kernel extensions, so hopefully they will be adding an extension point so that utilities like Little Snitch can continue to work. If you want to do novel things with the kernel that Apple hasn’t pre-planned for, it sounds like you’ll be out of luck.

Update (2017-06-29): See also: Little Snitch and Possible Deprecation of NKEs.

Bug in Skylake and Kaby Lake Hyper-threading

Henrique de Moraes Holschuh:

This advisory is about a processor/microcode defect recently identified on Intel Skylake and Intel Kaby Lake processors with hyper-threading enabled. This defect can, when triggered, cause unpredictable system behavior: it could cause spurious errors, such as application and system misbehavior, data corruption, and data loss.

It was brought to the attention of the Debian project that this defect is known to directly affect some Debian stable users (refer to the end of this advisory for details), thus this advisory.

Please note that the defect can potentially affect any operating system (it is not restricted to Debian, and it is not restricted to Linux-based systems). It can be either avoided (by disabling hyper-threading), or fixed (by updating the processor microcode).

Due to the difficult detection of potentially affected software, and the unpredictable nature of the defect, all users of the affected Intel processors are strongly urged to take action as recommended by this advisory.

Via Tom Harrington:

Check your Mac CPU with “sysctl machdep.cpu” and compare to this. [Skylake list, Kaby Lake list]

Developers who are concerned can use Instruments to disable hyperthreading until reboot. See Instruments prefs.

Unfortunately, the “Hardware Multi-Threading” setting in Instruments does not persist after the Mac reboots or sleeps, so you have to keep re-applying it. The good news is that Apple should be able to offer a software update that applies Intel’s microcode patch.

Update (2017-07-05): Xavier Leroy (via Hacker News):

Late April 2016, shortly after OCaml 4.03.0 was released, a Serious Industrial OCaml User (SIOU) contacted me privately with bad news: one of their applications, written in OCaml and compiled with OCaml 4.03.0, was crashing randomly. Not at every run, but once in a while it would segfault, at different places within the code. Moreover, the crashes were only observed on their most recent computers, those running Intel Skylake processors.


SIOU didn’t take my suggestions well, arguing (correctly) that they were running other CPU- and memory-intensive tests on their Skylake machines and only the ones written in OCaml would crash. Clearly, they thought their hardware was perfect and the bug was in my software. Great. I still managed to cajole them into running a memory test, which came back clean, but my suggestion about turning HT off was ignored. (Too bad, because this would have saved us much time.)

Update (2017-12-28): I contacted Apple in early August and was told that the bug would be addressed in High Sierra. However, as of macOS 10.13.2 there is no update for the processors. Mine still shows:

machdep.cpu.brand_string: Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz 6
machdep.cpu.model: 158
machdep.cpu.extmodel: 9
machdep.cpu.extfamily: 0
machdep.cpu.stepping: 9
machdep.cpu.signature: 591593
machdep.cpu.microcode_version: 88

I spent a couple weeks in December going back and forth with Apple’s support people, trying to get an answer. None of the advisors had even heard of the bug. Eventually, a senior advisor escalated the issue to engineering. The engineer confirmed that Apple is aware of the bug but does not yet have a fix. They will not say when or even if Apple will ship a fix. Apple’s policy is not to comment on unreleased products.

Looking at Intel’s spec sheet, it appears that KBL095/KBW095 were not fixed as of August, so perhaps Apple is waiting on Intel for the Kaby Lake fix. (Intel has had an update for Skylake CPUs since at least June, but it’s not clear to me whether Apple has shipped it.)

For now, Apple recommends keeping hyper-threading turned off to prevent data corruption. This can be done by unchecking the “Preferences ‣ CPU ‣ Hardware Multi-Threading” setting in Instruments. Unfortunately, this setting is not preserved if you sleep or restart your Mac. Apple confirmed that there is no way to make the setting stick. (Years ago, the nvram command could be used.)

My recommendation is to set the Mac not to sleep the CPU and to add Instruments as a login item so that you remember to disable hyper-threading when your Mac starts up.

It’s not clear to me whether the Xeon W processors in the iMac Pro are affected.

See also: ArsTechnica, Hacker News, MacRumors, OCaml Mantis, Reddit, StackExchange.

APFS Native Normalization

The iOS transition to APFS seems to have gone very smoothly except for some Unicode normalization issues. Apple never really explained to developers how they could make their code work properly, most were not aware that there were issues at all, and the necessary app modifications were difficult to develop and fully test. In my view, pushing this responsibility onto apps was a recipe for endless obscure bugs and poor performance.

At WWDC 2017, Apple essentially admitted that they had made a mistake and told us how they are going to fix it. There is a short-term fix and also a long-term fix that will require another file system conversion. This is not yet documented in the APFS Guide, but here’s a summary of the different cases:

Update (2017-12-14): Despite the native normalization, I’m seeing problems with Git and accented filenames on macOS 10.13.2. If I edit a file with such a name, Git sees it as a new file, and therefore sees two files whose names differ only in normalization. It’s somewhat tricky to then remove the original entry.

Google Will Stop Reading Your E-mails for Gmail Ads

Mark Bergen (via John Gruber, tweet, MacRumors):

Google is stopping one of the most controversial advertising formats: ads inside Gmail that scan users’ email contents. The decision didn’t come from Google’s ad team, but from its cloud unit, which is angling to sign up more corporate customers.


Ads will continue to appear inside the free version of Gmail, as promoted messages. But instead of scanning a user’s email, the ads will now be targeted with other personal information Google already pulls from sources such as search and YouTube. Ads based on scanned email messages drew lawsuits and some of the most strident criticism the company faced in its early years, but offered marketers a much more targeted way to reach consumers.