Xeno Kovah: macOS 10.13 EFI firmware integrity check | Hacker News Reader

Xeno Kovah: macOS 10.13 EFI firmware integrity check

twitter.com

88 pointstranspute21 comments

In 10.12.6 (and perhaps earlier) there's already a /usr/libexec/firmwarecheckers directory. It contains an "ethcheck" binary (with some odd permissions, "-rwx--x--x"... why allow other users to execute it but not read it?).

One of the options provided is: "ethcheck --send-change-in-firmware enable: Will allow ethcheck to send unexpected change in firmware binary to Apple."

Is stuff like "Thunderstrike 2" ( https://arstechnica.com/gadgets/2015/08/thunderstrike-2-root... ) common enough that they expect to find it in the wild and are scanning for this?

I don't think something needs to be common in order to be protected against.

It'd be great if the message shown is a little more direct than "Your computer has detected a potential problem", because having an unknown EFI is pretty worrying. With the current wording, there's a good chance I'd ignore it.

Until Apple can guarantee they have every single last version of EFI in their database, I think it is the best they can do. Those that know what that check is about are also generally the targets that would have to worry about it.

Great to see this level of transparency from Apple’s folks. (Also, hope he doesn’t get in trouble for this!)

The thread's gone.

http://archive.is/6IIDb

I would like to know a related thing with regards to mac EFI firmware. Does it support low battery ACPI events? How does macOS trigger low battery alarms? By polling?

I'm running Linux on my MacBook and it is irritating I cannot use a simple udev rule on to trigger suspend. To be fair most PCs don't support this either. Only some ThinkPads. It's usually my litmus test for Linux compatibility.

Macs use the ACPI Smart Battery Subsystem. The Linux SBS driver should be polling regularly and also receive GPEs when the battery reaches certain thesholds. But the polling frequency should be in the order of seconds, providing constant battery level progress and time to suspend at a critical condition.

Thanks. I didn't know SBS was the particular kernel module responsible for this. However, lsmod reports it's loaded by default in my stock Arch kernel and I assume it has always been.

I have never been able to get events through acpi_listen when the battery reaches particular thresholds. Thus, udev rules for critical battery levels never work.

Any ideas why this is not working? I'm using a MBA 11 inch late 2012. Possibly the most Linux-compatible Mac machine ever. All stock Intel hardware.

Xeno, please don't get yourself fired from Apple for leaks! Us apple users need you behind the coal fires keeping us safe!

Huh, and it was just deleted. Anyone screencap the whole thread?

https://web.archive.org/web/20170924180858/https://twitter.c...

Summary here: https://eclecticlight.co/2017/09/24/high-sierra-automaticall...

Something about that just strikes me as beyond creepy, regardless of whether it's for "security" or not.

”This will allow eficheck to send the binary data from the EFI firmware, preserving your privacy by excluding data which is stored in NVRAM”

How can they know that’s sufficient to preserve user privacy? The code sends data they don’t know of to Apple. That could contain anything, including compromising photos (not that likely) and private keys (slightly more likely)

Why would any of that be embedded in your EFI firmware blob?

Apple cannot guarantee I will not include any of that in my firmware.

They also should not be that surprised to find photos in my firmware, as they have shipped photos in their firmware in the past (https://www.nycresistor.com/2012/08/21/ghosts-in-the-rom/)

http://webcache.googleusercontent.com/search?q=cache%3Ahttps...

We need a TDR (Tweeted, Didn't Read) for things that should really be a blog post, not some long rambling series of Twitter posts.

Same thing for those bullshit screen shots of news releases that get posted to Twitter. Actually, those may be worse.

/offtopic

Apple doesn't like their engineers writing blogs. At best we can get a quick tweet storm before apple internal affairs finds the thread and gets it nuked.

Reply on news.ycombinator.com