Am 03.06.2012 08:57, schrieb Walter Dnes: > On Sat, Jun 02, 2012 at 07:36:51PM -0400, Michael Mol wrote > >> The BIOS will only load a signed bootloader. The signed bootloader >> will only load a signed kernel. > > OK, so I sign LILO. What code is in there that prevents LILO from > loading whatever kernel I've compiled? >
Nothing. The point is, if you sign software that is used (or can be used) for malware, your key will be blacklisted. That's why Fedora takes the measures I've listed: They don't want to have their key revoked. >> The signed kernel will...do whatever you tell it to do. > > Define "kernel"... no... seriously. > 1) Could it actually be a hypervisor? > > 2) Or maybe another copy of LILO which proceeds to load the actual > kernel? > Sure, whatever floats your boat. UEFI only checks the boot loader directly. After that, it is the boot loader's responsibility to keep the next stage secure. But if you allow unchecked access to the hardware through whatever signed code you have, your key will be blacklisted. To quote Matthew again: > Secure boot is built on the idea that all code that can touch the > hardware directly is trusted, and any untrusted code must go through > the trusted code. This can be circumvented if users can execute > arbitrary code in the kernel. So, we'll be moving to requiring signed > kernel modules and locking down certain aspects of kernel > functionality. The most obvious example is that it won't be possible > to access PCI regions directly from userspace, which means all > graphics cards will need kernel drivers. Userspace modesetting will > be a thing of the past. Again, disabling secure boot will disable > these restrictions. Regards, Florian Philipp
signature.asc
Description: OpenPGP digital signature
