Matthew Garrett Elaborates More On Lockdown + Secure Boot Pairing

[GunpowaderGuy]

"the alternative is to enable it everywhere" no , the most logical alternative is to let it be optional , idependently of secure boot
"what distributions wants" did i missed something or did he failed to provide sources ?

[indepe]

The blog post seems to only repeat arguments that Linus has already rejected as not convincing.

[chithanh]

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

The IBM PC had no DMA? Umm...

In any case, UEFI did not solve any problems that had not been solved already. IEEE 1275 / Open Firmware had been around for a while, and its spec is just 266 pages compared to over 2000 for the horribly complex UEFI.

[V10lator]

The reason it's integrated with UEFI secure boot is because that's the policy most distributions want

He mentions that when you build the kernel as a UEFI executable, you can't supply kernel parameters.

Distributions want systemd. Systemd has systemd-boot which is a EFI executable being able to load other EFI executables and it passes a cmdline when loading a linux kernel as EFI stub. I'm pretty sure distros want such a boot manager between UEFI and the kernel anyway. So the argument is completely invalid.

[stalkerg]

Distributions want systemd. Systemd has systemd-boot which is a EFI executable being able to load other EFI executables and it passes a cmdline when loading a linux kernel as EFI stub. I'm pretty sure distros want such a boot manager between UEFI and the kernel anyway. So the argument is completely invalid.

I have already it without systemd and with OpenRC.

[brrrrttttt]

I have already it without systemd and with OpenRC.

What does that have to do with systemd-boot (aka gummiboot)?

[brrrrttttt]

Distributions want systemd. Systemd has systemd-boot which is a EFI executable being able to load other EFI executables and it passes a cmdline when loading a linux kernel as EFI stub. I'm pretty sure distros want such a boot manager between UEFI and the kernel anyway. So the argument is completely invalid.

Exactly. I know of no distros building their kernel as a UEFI image? If they did, are there any BIOS bootloaders that are able to run a UEFI image? Maybe GRUB can do that?

[arbition]

Matthew Garrett's proposed solution to tying this up with secure boot is to disable secure boot validation entirely. A very simple command to be sure (one liner, somehow cannot be run remotely), so how many how to guides will that end up in, in the same way that SELinux was often disabled in production? Perhaps some more thought into the structure of Lockdown should happen before we start to tie it up with something that most people aren't aware of.

[carewolf]

I sure as hell don't want it from my distro. Secure boot is one thing, but why would I want my own computer to be running in a gimped kiosk mode where I am no longer in control?

[madscientist159]

I sure as hell don't want it from my distro. Secure boot is one thing, but why would I want my own computer to be running in a gimped kiosk mode where I am no longer in control?

Hate to break it to you, but you haven't been in control of any recent computing hardware with any real power behind it for a long time. Look into the ME, the PSP, and the lengths required to get away from them with something like the Talos II (benchmarked recently here). It's not a pretty picture...