This article is more than 1 year old
Microsoft's Lennart Poettering proposes tightening up Linux boot process
Building your own initial RAMdisk? That's insecure!
Lennart Poettering's latest blog post proposes moving the Linux boot process into a "Brave New Trusted Boot World" of cryptographically signed Unified Kernel Images.
Agent Poettering offers a mechanism for tightening up the security of the system startup process on Linux machines, using TPM 2.0 hardware. In brief, what he sees as the problem is that on hardware with Secure Boot enabled, while the boot process up to and including the kernel is signed, the next step, loading the
initrd, is not. That's what he wants to fix.
The initrd is the "initial RAM disk." It's how Linux distributions cope with the issue of booting a machine on wildly different hardware without building a unique custom kernel for every individual machine. The bootloader loads the kernel and the initrd into memory, and then as the kernel starts to run, it has a temporary filesystem ready for it in memory, from which it can load any additional device drivers it needs – including device drivers that might be needed in order to find its real root filesystem, which could be anywhere: not just on a local drive, but on FibreChannel, InfiniBand, a USB key, a network drive via iSCSI or AoE or NFS, or whatever.
The problem is that other device drivers may need to be in the initrd, too, such as graphics drivers. If you have Nvidia graphics drivers, for instance, every time the drivers are updated, the distro builds a new initrd.
This works, but the problem is that locally generated initrds are potentially insecure. In principle, malware or an intruder could insert malicious code into the initrd, and it will be loaded every time your system boots, even if no other copy of that malicious code exists anywhere else on your hard disk.
The situation regarding full-disk encryption (FDE) is worse: the initrd is how Linux boots off local drives with FDE. As The Reg FOSS desk discovered when putting Linux on a new Dell Latitude, some forms of full-disk encryption can unlock encrypted disks without a password using information stored in the TPM chip's Platform Configuration Registers. Agent P is very concerned about the way that code in the initrd has access to TPM PCRs.
He outlines the current boot process as follows:
Boot chain is typically Firmware →
grub → Linux kernel →
dracut or similar) → root file system
He lists seven different problems with this sequence of events, and the first threat he mentions is the "evil maid" attack, as discussed on The Reg as long ago as 2009.
His proposed solution is the Unified Kernel Image:
These UKIs are the combination of a Linux kernel image, and initrd, a UEFI boot stub program (and further resources, see below) into one single UEFI PE file
For the avoidance of doubt, a PE file is a Microsoft "Portable Executable," as we explained when introducing the Redbean 2 multiplatform binary. Yes, that's how UEFI works; indeed, as he notes while explaining the boot process:
A boot component originating in the Linux world, which in a way extends the public key database SecureBoot maintains (which is under control from Microsoft)
- Update time for Ubuntu: Last version of Linux kernel 5.19.17 hits
- Lash#Cat9: A radical new Linux UI for keyboard warriors
- Intel DAOS 2.2 and Red Hat Stratis 3.3 released
- OpenBSD 7.2: The other other FOSS xNix released, runs on Apple M2 Macs
Yes, as with much of this stuff, Microsoft has a hand on the reins, and already some are calling this another step in the company's long-established Embrace, Extend, Extinguish maneuver – for instance, the very first comment on the Hacker News thread on the topic.
As per usual with Poettering pronouncements, we predict panic and parsimony. In some scenarios, this could provide useful protection. As The Reg noted over a decade ago, when UEFI was new, Secure Boot could be a problem for Linux, and we linked to a blog post on the subject by the boot-up boffin supreme Matthew Garrett. However, in time, enterprise distros embraced Secure Boot, and ChromeOS Flex actually recommends it. This time around, Dr Garrett is encouraging:
this is very nice. Needs some work […] but definitely a big step in the right direction.
If MJG approves of it, we would not dare to differ. All we would note is that this potentially widens the divide between enterprise distros, increasingly locked-down, secured, and ever more difficult to customize, and the wild, free-wheeling world of Free Software OSes by and for those who don't want others, or corporations, to be able to control their computers.
As Aldous Huxley wrote:
Most men and women will grow up to love their servitude and will never dream of revolution.
Actual happiness always looks pretty squalid in comparison with the overcompensations for misery.
On x86, at least for now, you can turn off Secure Boot. You can't on Arm machines, which in our opinion a decade ago was one reason that the Surface RT didn't sell. Trusted Computing, after all, is not about you trusting your own computer. There's already a movement against systemd, and we suspect that this will now widen to be anti-UKI as well. ®