An Overview of Secure Boot in Debian | Hacker News Reader

An Overview of Secure Boot in Debian

debamax.com

64 pointsdeadbunny15 comments

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.)

AIUI, 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.

> 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.

Thankfully, you can find code to get the bios master password and disable secure boot for most PCs. Not true, though, for some more niche platforms.

Microsoft, though, can change their mind anytime and force manufacturers to require secure boot, and to get rid off the ability to disable it.

Current policy: https://www.extremetech.com/wp-content/uploads/2015/03/windo...

More info: https://www.extremetech.com/extreme/201722-linuxs-worst-case...

I am hopeful that Microsoft would not do such a thing. They seem to be doing rather well at the whole "we're not an evil megacorp, trust us please" thing with there recent contributions to open source etc. I hope they wouldn't want to throw that away.

They did do it on the ARM windows RT laptops, though that line of products is now defunct.

The more frustrating thing about those machines is that there are two Secure Boot root keys in the MS program, one for Microsoft products (e.g., Windows) and one for everyone else, including both third-party hardware drivers and third-party OSes like Linux distros. But on the ARM Surface devices, Microsoft built them so all of the UEFI binaries were signed by the MS-themselves key, so even if you got an MS-signed key like this article is talking about, it wouldn't let you boot a non-Windows kernel.

For certain security profiles in Windows 10 and related Windows Server versions, it's required that Secure Boot uses customer keys and MS keys are purged (you have to sign your installs with your own keys).

Due to that, any "enterprise level" hardware has to have a way to switch Secure Boot into "SETUP" mode, which cleans all keys and let's you put in your own master keys.

You don't need "code" or a "bios master password" - if there is no end-user-set firmware password, you can just go into the menu and change "Secure Boot" to "no."

(If there is a user-set firmware password, and you don't know it, you're not the end user and you can't change how someone else's computer boots up. That's been true for decades: setting a firmware password and maintaining sufficient control of the machine to prevent it from being opened is the standard way to prevent someone from booting your computer into a live CD and messing with it.)

Yes, I should have included the context that I deal with a fair number of used PCs.

Sans that code and master password, though, you can mess with someone by setting their BIOS password. The master password is still useful even if you're the original owner.

>if there is no end-user-set firmware password, you can just go into the menu and change "Secure Boot" to "no."

The above expected behavior is still quite prevalent.

However with PC's such as the Acer Aspire Switch 10e, if there is no end-user-set firmware password, you can NOT just go into the menu and change "Secure Boot" to "no." The option will not be available.

The latter would seem to work as an anti-recycling feature. IOW, since the default user behavior is to not set a BIOS password, anyone disabling secure boot in order to use Linux will have had to set a BIOS password on such hardware first, even if they would not have normally used a BIOS password otherwise.

Later, when the hardware is passed on to a second-hand user without knowledge of the BIOS password, it will not be so easy to fully repurpose the machine without being able to get into the BIOS to make appropriate changes.

While this works in practice, it disables full disc encryption (bitlocker) support on Windows for dual-booters.

> you can find code to get the bios master password and disable secure boot for most PCs

Why would you do that?

Secure boot literally and exclusively increases the security of your PC. Why disable it?

With many modern distros (Fedora, Ubuntu, etc) it works out of the box. It’s not a hindrance to competently put together FOSS OSes.

Sounds like you aren't having issues. I've seen this screen enough that I don't want to see it again: https://linuxmint-installation-guide.readthedocs.io/en/lates...

Not once. My OS knows how to Secure boot and don’t fuck up essential things like that.

Reply on news.ycombinator.com