Garrett: Secure Boot and Restricted Boot

Case 1: Malware uses a vulnerability in the kernel to join a botnet and hide itself from userspace. This is out of scope for secure boot so not relevant.

Case 2: Malware uses a vulnerability in the kernel to modify the boot sector so it gets run the next time the computer starts up. The next boot the firmware checks the boot sector and complains to the user that there's an unverified boot sector and that the user should use a boot CD to clean it. Secure Boot achieves it's goal because it's impossible for the malware to install a boot sector that passes the test.

Now you can say that the malware will just install itself into /etc/rc.d/ instead and you'd be right. That's just because no-one has written the code to do any verification on that directory, not because it's not possible. Those tests would be effective at preventing the malware running on boot *even if the kernel was insecure*.

The only thing Microsoft (really Verisign) requires before signing a bootloader is that it can't be used by malware to subvert the windows boot process so it can pass the boot sector test. But this is a social problem which can't be solved by technical means. That's why a bootloader which says "Hi! You're booting MyBootLoader. If this is not what you're expecting contact technical support. Press any key to continue." would probably get signed since it won't allow malware to hide itself.