Matthew Garrett Elaborates More On Lockdown + Secure Boot Pairing

[phoronix]

Phoronix: Matthew Garrett Elaborates More On Lockdown + Secure Boot Pairing

A few days back we covered the heated exchange on the kernel mailing list over the path being pursued by the Linux kernel "lockdown" patches. Those back and forth messages between Google's Matthew Garrett and Linus Torvalds have now spilled over into a blog post by Garrett...

http://www.phoronix.com/scan.php?page=news_item&px=MJG-UEFI-Secureboot-Lockdown

[tzui]

I have dozens of scenarios in mind where this lockdown feature could be useful but where you don't have secure boot like VMs, Chromebooks (protection by screw) and ARM systems which load the kernel from SPI memory.

[lucasbekker]

I have dozens of scenarios in mind where this lockdown feature could be useful but where you don't have secure boot like VMs, Chromebooks (protection by screw) and ARM systems which load the kernel from SPI memory.

I might misunderstand the discussion, but I beleive that the main problem is not so much that lockdown can't be enabled without secureboot, but that it is hard to disable with secureboot...

[brrrrttttt]

I might misunderstand the discussion, but I beleive that the main problem is not so much that lockdown can't be enabled without secureboot, but that it is hard to disable with secureboot...

Yep, that's the main sticking point.

[R41N3R]

UEFI is a terrible thing, it is slow, bloated and insecure. I can totally understand that a Linux developer doesn't want to depend from something like this for a security feature. How should this so called secure boot thing be secure if it is not open source. I distrust this, I have not seen a device where I can remove the vendor keys from my machine.

[OneTimeShot]

IMO - there is a lack of joined up thinking here.

Hardware launches UEFI. UEFI secures boot processs. Secure Boot secures Grub. grub launches Linux with a known-good commandline. Linux launches the SELinux Policy. The SELinux Policy locks down the kernel. The Kernel provides access control controlling the modification of everything.


that’s complex enough - why add more “magic lockdown” into the security chain? Especially given that UEFI signing is probably the weakest security technology in that list.

[RahulSundaram]

IMO - there is a lack of joined up thinking here.

Hardware launches UEFI. UEFI secures boot processs. Secure Boot secures Grub. grub launches Linux with a known-good commandline. Linux launches the SELinux Policy. The SELinux Policy locks down the kernel. The Kernel provides access control controlling the modification of everything.

SELinux deals with userspace through the kernel. It doesn't lockdown the kernel itself

[StefanBruens]

UEFI is a terrible thing, it is slow, bloated and insecure. I can totally understand that a Linux developer doesn't want to depend from something like this for a security feature. How should this so called secure boot thing be secure if it is not open source. I distrust this, I have not seen a device where I can remove the vendor keys from my machine.

You are confusing the UEFI standard with UEFI implementations. There are at least 2 common opensource UEFI implementations, one is U-Boot, the other one is EDK2/TianoCore. EDK2 is also used for a lot of of Vendor UEFI implementations, blame the vendors for keeping parts of the implementation closed.

Neither EDK2 nor U-Boot are slow, the biggest slowdowns in the boot process is waiting for the hardware (e.g. clocks, PLLs) to become initialized, with delays required by the chip manufacturer.

BIOS implementations are not open source (which you seem to set equivalent to secure), but you trust them more?

UEFI does solve a number of problems BIOS had (e.g. clean handover between boot services and operating system), it is able to cope with todays computers (the IBM PC had no multicore multi-GHz CPU with frequency and voltage scaling, nor USB, nor PCI(e), no MMU, no IOMMU, no DMA, ...).

[Terrablit]

Having this in the kernel will definitely get in the way of embedded device hacking. On the other hand, though, the patch already exists, and vendors are notorious for keeping a separate kernel tree and not mainlining it. I have several devices that are extremely hard to work with due to vendor shenanigans. Realistically speaking, assuming that we can avoid this if it's not mainlined is a bit unrealistic.

I wasn't aware of the Alt+SysRq+X trick, so it's good to know there's a runtime way to deal with this. Of course, it does require a keyboard, so it might still be useless with embedded hardware. And disabling it manually every boot would be obnoxious, in the scenario where a vendor won't let you disable secure boot or adjust the signing keys.

And if distros ship two kernels (one with this, one without), people can still get what they want without having to compile themselves. But in that case, the distros will still be shipping kernels that can be used as part of an attack chain. So it doesn't really solve that issue... But I guess at least the default kernel would be less at risk.

He mentions that when you build the kernel as a UEFI executable, you can't supply kernel parameters. And that it's the scenario where this is needed. Perhaps the patch should be based around detecting that use case at runtime or compile time and securing it then. Most users don't use this option - we prefer bootloaders for flexibility. So if this only occurs when people deliberately compile the kernel for UEFI and boot directly to Linux, it's less controversial.

MJG did a much better job explaining this here rather than in the mailing list. Over there, he was kind of dismissive about complaints and just assumed everyone would and should want it. He still hasn't answered all questions appropriately, though. Gotta fill those gaps.

[tg--]

You are confusing the UEFI standard with UEFI implementations. There are at least 2 common opensource UEFI implementations, one is U-Boot, the other one is EDK2/TianoCore. EDK2 is also used for a lot of of Vendor UEFI implementations, blame the vendors for keeping parts of the implementation closed.

Neither EDK2 nor U-Boot are slow, the biggest slowdowns in the boot process is waiting for the hardware (e.g. clocks, PLLs) to become initialized, with delays required by the chip manufacturer.

BIOS implementations are not open source (which you seem to set equivalent to secure), but you trust them more?

UEFI does solve a number of problems BIOS had (e.g. clean handover between boot services and operating system), it is able to cope with todays computers (the IBM PC had no multicore multi-GHz CPU with frequency and voltage scaling, nor USB, nor PCI(e), no MMU, no IOMMU, no DMA, ...).

TianoCore is indeed Open Source, and indeed the basis for many UEFI implementations. But that doesn't change the fact, that no hardware is actually shipped with an Open Source UEFI implementation, even the TianoCore based ones are heavily modified and generally closed source software (having an open source basis for your closed source piece of software does not make it open source when the license is a non copyleft one!).

U-Boot is no UEFI implementation, it could probably more reasonably described as a combination of boot firmware and boot loader, so what it does is bring up hardware and load the next component: that one can be either another boot loader, a OS kernel, or an EFI binary.
Loading an EFI binary doesn't make u-boot an UEFI implementation, it instead implements the UEFI Application Protocol, which is the tiny tiny part of UEFI handling the loading of EFI binaries (like grub2, the linux kernel, or the windows kernel).

Long story short: there still is exactly one open source UEFI implementation and that one is TianoCore. There is exactly 0 hardware shipping with open source TianoCore, even though there is some based on it.
The situation is pretty much the same as with other major BSD licensed software: The PS3 might run on the FreeBSD kernel which is open source, but no source code has ever been released.