How do we defend against this? - Linux edition
So, I gloated for 30 seconds that this didn't affect me because I use Linux. Then I started thinking about how to defend against this sort of thing... at least from entities trying to be "helpful" (not trying hard to be malicious).
It is certainly true that EFI code can do anything it likes to the disks, or to the RAM contents before dispatching the kernel. However, all my disks are encrypted (data disks and root disk). Except for /boot (which contains the kernel and the initrd) and /efi. /efi is trivial for the board EFI code to change, but that doesn't do anything the board can't do directly so isn't much worth worrying about, I think.
The kernel and the initrd are more of a problem. But hacking my kernel image is unlikely for something trying to be helpful, I think. I suppose it could manipulate my initrd either on disk or after loading it easily enough - as far as I know it isn't signed or encrypted? I ought to check.
On the other hand, my normal Linux boot uses grub (or refind on some systems). Unless the EFI code decided to bypass those boot loaders and load the kernel and a modified initrd directly it isn't going to get anywhere. And I would certainly notice bypassing those (still assuming it isn't malicious and replicating my normal boot output to hide itself).