Garrett: Secure Boot and Restricted Boot

In what way is this architecture for simple integrity checking of the boot firmware and boot loader insecure against remote unauthorized attackers modifying the firmware or boot loader to hide and persist their root kits? The only attack surface I can see is the code which reads config variables which are under the possible control of an attacker, and I'm sure that code is limited and could be audited or fixed in the field to close any holes which are discovered.

Other application-security issues (buffer overflows in the browser or OS) are really not what this is about and no one is pretending that this is a miracle cure for unrelated security problems.

> 2. that anything beyond "make grub* be loaded, to load whatever I want after" is a waste of time and effort AND a collaboration with microsoft's efforts to keep linux out of the next generation of PCs|tablets|whatever_gadgets coming.

So any integrity checking of the kernel by the bootloader or of userspace by the kernel, none of which is defined by UEFI Secure Boot, is a bad thing? Is tripwire or AIDE a bad thing too? The whole point of the shim is to have total control over what boots after and to still allow you to verify that it hasn't been modified without your permission. A local user can trojan their own system if they want, I guess, Secure Boot won't attempt to stop them, but a remote attacker won't be able to do so from the running OS. At least that's the intent.

I don't see how MS is keeping Linux off the next generation of PCs when they already signed a boot loader that can boot any Linux system on a PC. As far as other gadgets, they are a mix of open and restricted devices, and no one is arguing against fighting boot-locking whenever it is encountered, MS isn't unique in this regard, most of the boot locked devices run Linux.