If the EFI firmware has been modified by a rootkit, surely it'll try to hide itself and present "valid" firmware data to the OS, and thus avoiding detection by this tool, right?
I'd really like to know the mechanism used for this. Currently Apple has issues with macOS firmware updates done on networks with proxies.<p>Specifically, the Touchbar updates have no concept of proxies and will cause the machine to appear to hang for a while (~20 minutes, IIRC) on boot when they can't directly phone home. This is a big problem on some large corporate networks.
Personally, I use rEFInd to manage my MBP's OS installs. I know that it installs itself to the EFI partition, but would that cause this service to identify an insecure/corrupted/whatever EFI?
This feature was the subject of a talk at Ekoparty:
<a href="https://www.ekoparty.org/charla.php?id=798" rel="nofollow">https://www.ekoparty.org/charla.php?id=798</a>
So the firmware could be compromised for up to a week, allowing a malicious 3rd party that long to exfiltrate whatever they want? If the problem of fake firmware is real, why not check it at every boot? Why not implement both UEFI Secure Boot, and also Measured Boot?
I wonder if there'll be any transparency around the database of known 'good' firmwares? For example, could a state actor force inclusion of a 'bad' firmware in the list? That's rhetorical, but the question is wouldn't it be better if end users could have visibility into the list of valid hashes? A count of the prevelance of each hash would pretty quickly highlight any with only a handful of appearances in the wild.
I'm a little surprised by how little chest thumping there is about apple collecting telemetry like this. I expected this to be full of people saying that you should only use tails and tor from a faraday cage.<p>Pleasantly surprised.