LWN: Comments on "Systemd takes steps toward a more secure boot process"

TPM 2 policy is more flexible than that, maybe too flexible.

nullcast — Thu, 09 Jan 2025 18:07:49 +0000

"TPMs don't have a native way to combine the two different kinds of policy."

Is this because it's trying to be TPM 1.2 friendly? Because it seems patently false for TPM 2.0 given stuff like policy ors, and the ability to accept any policy signed by the same key.

the weak link being secure boot implementations themselves

kevincox — Thu, 09 Jan 2025 13:22:06 +0000

If there is no good story for actually booting a verified OS then there is no incentive to fix the firmware. There is a chicken and egg problem here and one missing link doesn't mean that we should finish the other links.

If Linux has a robust and easy to use secure boot story then there will be a market demand for a manufacturer that ships secure (and hopefully open) firmware.

the weak link being secure boot implementations themselves

patrick_g — Fri, 03 Jan 2025 08:48:46 +0000

I second that. I also own a NovaCustom laptop with Dasharo based coreboot (and deactivated Intel ME) and and it's a very good machine.
With this coreboot-based firmware and the systemd-boot loader I have a free (modulo some blobs), modern, secure and minimalist boot process on this laptop.

the weak link being secure boot implementations themselves

paulj — Thu, 02 Jan 2025 16:34:50 +0000

Just to add a data-point, I have a NovaCustom laptop with Dasharo based coreboot. Works great. You can turn off the Intel ME. EU based company, so might be better in logistical terms for some.

UKIs sound like Flattened Image Trees with new paint

Cyberax — Thu, 26 Dec 2024 22:27:03 +0000

> I mean, how often is EFI available for "embedded" hardware?

UKIs can easily be used with other early boot systems. The main complexity was in getting everything that is needed for boot to be properly measurable.

UKIs sound like Flattened Image Trees with new paint

bluca — Thu, 26 Dec 2024 18:45:44 +0000

Pretty much always nowadays on devices that matter (ie, have been built from ~2010 onwards - if you are doing retrocomputing on CPUs from the 70s, 80s or 90s that's great and hope you have the best of times, but out of scope of anything I care about), as uboot can be configured to provide a UEFI interface, allowing one to be mostly free of the pain of dealing with it. Or at the very least, delegate all that pain to the firmware team, and be blissfully oblivious from the bootloader and OS viewpoints ;-)

UKIs sound like Flattened Image Trees with new paint

marcH — Thu, 26 Dec 2024 18:36:15 +0000

You've been comparing two options but how often is there even a choice? I mean, how often is EFI available for "embedded" hardware? (conversely: how often do servers support u-boot)

the weak link being secure boot implementations themselves

marcH — Thu, 26 Dec 2024 18:32:28 +0000

> I get where this is coming from, but it's almost lipstick on a pig at this point with so many OEM firmware chains already compromised before the OS atomic image is verified.

Even if they were only a small number of non-compromised OEMs left, that "lipstick on a pig" would still help them complete the chain and compete; that's a good thing.

Security is only as strong as the weakest link; you have a valid point there. But that does not mean work on the other links should stop and wait until that weakest link gets fixed.

Also, the location of the "weakest link" is heavily dependent on the context and threat model. If every link keeps making excuses by pointing fingers at other links then nothing ever gets done.

the weak link being secure boot implementations themselves

bluca — Wed, 25 Dec 2024 12:44:16 +0000

This is very much not true, otherwise malware wouldn't be actively trying to exploit vulnerabilities in Shim and GRUB2 in order to bypass secure boot, in the wild.

UKIs sound like Flattened Image Trees with new paint

bluca — Wed, 25 Dec 2024 12:41:24 +0000

Sure, but only u-boot can load those, it's a format specific to that bootloader. UKIs are just PE binaries, so anything that supports EFI can launch them, including directly from the firmware. Also the userspace tooling around FIT in my experience is really, really painful to use, and often breaks compatibility. We use them at $work, and are working to migrate to UKIs, and honestly cannot wait, the ecosystem is so much better in every way it's not even close.

UKIs sound like Flattened Image Trees with new paint

alison — Wed, 25 Dec 2024 04:52:53 +0000

Flattened Image Trees have longed included devicetrees and initrds as well as multiple kernel versions. Cryptographic signing of FITs has been customary for years. Embedded devices, often ARM-based, have long used FITs, which can be created and manipulated in Debian with u-boot-tools. Perhaps UKIs now add support for GRUB, ACPI and x86_64.

the weak link being secure boot implementations themselves

Cyberax — Tue, 24 Dec 2024 23:12:38 +0000

You can approach that with Coreboot. Notable, System76 sells laptops with it: https://github.com/system76/firmware-open

It's not completely open, there are still blobs for some devices. I guess RISC-V based systems will be the top contenders for fully-verified boot.

the weak link being secure boot implementations themselves

Heretic_Blacksheep — Tue, 24 Dec 2024 19:49:08 +0000

I get where this is coming from, but it's almost lipstick on a pig at this point with so many OEM firmware chains already compromised before the OS atomic image is verified.

It would be nice if a fully verifiable firmware chain was independently verifiable and as easily updated as an open source operating system, but that's not the case in the vast majority of client systems, nor is it all that common with server hardware.

Purpose of addons

bluca — Tue, 24 Dec 2024 15:16:55 +0000

> Add-ons are not going to become completely obsolete, however. Their primary use going forward is likely to be providing microcode updates, which usually have a different lifecycle than the kernel.

The main purpose of addons remains the same: to allow the hardware/platform owner to augment a UKI provided by the OS vendor. These two entities in many cases will not be the same, and won't have access to the same signing keys. As a user, you usually don't wnat to have to take care of your own kernel, initrd, etc. As an OS vendor, you don't want to have to provide any hardware-local customization for users, as it just doesn't scale outside of purpose-built and integrated OSes and devices.

The purpose of the multi-profile support in the UKI instead, is for the OS vendor to provide common alternatives (IE: debug mode, recovery mode, etc).