4 ms·
As far as I know, the Debian secure-boot-signed-GRUB image uses the same patches/config as ~all other distros except Ubuntu: the only kernels GRUB will load are
by geofft 8y ago
As far as I know, the Debian secure-boot-signed-GRUB image uses the same patches/config as ~all other distros except Ubuntu: the only kernels GRUB will load are Debian-signed kernels or (IIRC) those signed by some other key in the firmware variable of trusted keys. The effective policy is "Only code that chains to a trusted root key may run in ring 0." I think they've also got the kernel patches.
Ubuntu has a different interpretation of the policy: they go with "Only code that chains to a trusted root key may run before ExitBootServices()." ExitBootServices() is a UEFI function call that hands over machine control (interrupt handlers, memory maps, ability to boot multiple CPUs, etc.) from UEFI to the code that calls it, and also makes certain firmware variables—notably the trusted keys, whether Secure Boot is enforced, etc.—read-only (usually by cutting power to an EEPROM write pin or something). You can either call it in your bootloader, and have the bootloader do a traditional handoff to the kernel, or you can load the kernel itself as an EFI binary and have it ExitBootServices() once it's ready. In GRUB, the `linuxefi` command does EFI handover and the `linux` command does traditional (multiboot, in GRUB's case) handover.
So Ubuntu's signed shim+GRUB is willing to boot unsigned/untrusted kernels as long as you do so with the `linux` command, and I think nobody else's shim+GRUB are.
Who's right is a matter of how you interpret the mission of Secure Boot and its threat model. It's certainly the case that Ubuntu's approach is a lot easier to implement: in particular they don't do any kernel lockdown either, so you can load random kernel modules, have untrusted IOMMU operations, load unsigned hibernation images, etc. in the Secure Boot pathway. In other distros you can't (or at least you need to generate and enroll your own key and then sign your kernel modules with that). So Ubuntu had Secure Boot for a long while, and Debian only has it now.
(In fact I use Ubuntu's shim+GRUB to boot Debian Stretch on my laptop without turning off secure boot. In one sense, it defeats the point; in another sense, the mere existence of Ubuntu's shim+GRUB also defeats the same point because an attacker could just install them, so I might as well.)
- 0815test 8y agoAIUI, you can use the shim to boot end-user-enrolled code, even if it's not signed by the MS key, but it will only do so pursuant to direct user interaction. So the shim effectively replicates the standard SB model, where the end-user has the option to disable it or not in the BIOS, but it's enabled by default.
- josteink 8y ago> It's certainly the case that Ubuntu's approach is a lot easier to implement: in particular they don't do any kernel lockdown either, so you can load random kernel modules, have untrusted IOMMU operations Not true. If you don’t believe it, try installing virtualbox from Oracles prebuilt repo (which doesn’t do DKMS). Their vbox.ko won’t load with Secure boot on, because it’s not signed. The solution is to load vbox with signed modules from the Ubuntu standard repos.