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."
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.
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.
”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)
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.
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?