
An Overview of Secure Boot in Debian - deadbunny
https://debamax.com/blog/2019/04/19/an-overview-of-secure-boot-in-debian
======
geofft
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.)

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

------
tyingq
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...](https://www.extremetech.com/wp-
content/uploads/2015/03/windows-10-secure-boot-1280x800.png)

More info: [https://www.extremetech.com/extreme/201722-linuxs-worst-
case...](https://www.extremetech.com/extreme/201722-linuxs-worst-case-
scenario-microsoft-makes-secure-boot-mandatory-locks-out-other-operating-
systems)

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

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

