Re:Xeno Kovah: macOS 10.13 EFI firmware integrity check
by 0x0 on Sunday September 24, 2017 @04:16PM
(#15326310)
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."
Re:Xeno Kovah: macOS 10.13 EFI firmware integrity check
by andr on Sunday September 24, 2017 @06:44PM
(#15326901)
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.
Re:Xeno Kovah: macOS 10.13 EFI firmware integrity check
by X-Istence on Sunday September 24, 2017 @07:50PM
(#15327132)
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.
Re:Xeno Kovah: macOS 10.13 EFI firmware integrity check
by nextos on Sunday September 24, 2017 @04:30PM
(#15326354)
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.
Re:Xeno Kovah: macOS 10.13 EFI firmware integrity check
by foodstances on Sunday September 24, 2017 @05:34PM
(#15326609)
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.
Re:Xeno Kovah: macOS 10.13 EFI firmware integrity check
by nextos on Monday September 25, 2017 @08:05AM
(#15329689)
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.
Re:Xeno Kovah: macOS 10.13 EFI firmware integrity check
by Someone on Sunday September 24, 2017 @06:58PM
(#15326967)
”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)
Re:Xeno Kovah: macOS 10.13 EFI firmware integrity check
by sdfgelgh43oito3 on Sunday September 24, 2017 @08:51PM
(#15327337)
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?
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.
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.
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)
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/)
Same thing for those bullshit screen shots of news releases that get posted to Twitter. Actually, those may be worse.
/offtopic