Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

So what's your "conspiracy" here? What is secure boot-only? Secure boot with systemd-boot has been possible for years. Just that the typical setup has not been very secure because the initrd and the kernel command line where already unsigned.

I see no problems with secure boot from a freedom perspective as long as the owner of the computer can install their own trusted public keys. There might be industry players that would like to remove that possibility. But why Poettering's work would make that easier I fail to see.

Do you think once a real secure Linux boot is possible they will remove machine owner rights and you have to buy a signed Linux from Microsoft? Or from a Microsoft/IBM/? consortium super monopoly?



> Secure boot with systemd-boot has been possible for years.

It was not, ironically because of Microsoft. Shim is by policy effectively only allowed to boot grub2. So systemd-boot can't be used OOTB on secure boot enabled systems, you'd have to enroll your own key.


> It was not,

It has been possible for years. I have used it for 4 years myself and I was not the first adopter.

> Shim is by policy

I am not talking about shim, you don't have to use it.

Here's how to do it:

1. You erase the whole key database from UEFI (That possibility was some agreement between antitrust authorities and Intel and/or Microsoft that such possibility must be provided because Wintel was in a a dominating marketing position. On Arm devices it is often not possible, Windows / ARM is not in a dominating position and antitrust was not relevant.)

2. You generate your own key pairs.

3. The public ones you install into the secure boot database of UEFI.

4. You sign your UEFI application with your private key.

I have done that with `systemd-boot` and with the Linux kernel (containing the UEFI stub). Works in both cases. I used the instructions from https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki%27s_EFI_Inst... 4 years ago and still do it the same way today.


On some Lenovo machines (x86) deleting the key database can brick the machine. So while you can technically do it in practice you can't.


Do you have a reference?

Deleting the key database can not be done programmatically (unless UEFI has a bug). In all machines I have looked it's an option in the BIOS. So that should be clear case of warranty repair. Which of course does not help you if you do it after warranty has ended.



Thanks for the link.

I guess it remains unclear whether it was a firmware bug that has since been corrected or whether it depends on how exactly the user installs their own keys.

The reply the UEFI itself would be signed and if you delete the matching keys from the relevant DB UEFI would no longer start does not sound right to me.

Good the see that the option exists for AMD, too. I guess AMD had no dominating market share when secure boot was introduced. So they would probably not be legally obliged to provide it? Hopefully market power of those requiring independence of Microsoft is big enough to keep it that way.


This sounds worrisome. Could you explain more? How can this brick a machine?


Some pieces of firmware on the machines are signed by the same keys in the secure boot database. Deleting the keys ends up blacklisting the firmware and so now the machine can't start up correctly because it no longer trusts hardware it needs to work.


I think they will better integrate systemd-boot with secure boot and eventually revoke access to the current shim signer, in essence forcing major distros to adopt systemd-boot.

I can't exactly figure out how they'd use that level of control over the Linux boot, but I'm not a huge fan of them having it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: