InitWare, a portable systemd fork running on BSDs and Linux

The problem with boot security is that the computer has no way to know its owner from someone who isn't its owner. All it can go on is who was there first. Which, you guessed it, was Lenovo.

I have no problem with secure boot as a concept but I don't know how to implement it so it can't be used to lock you out of your own computer. And an implementation which allows that is worse than no implementation.

sbctl [0] makes secure boot a lot easier. you just enable setup mode from BIOS and it will take care of enrolling and managing the keys. Are you immibis from libera.chat by any chance?

[0] - https://github.com/Foxboron/sbctl

The owner is whoever controls the installed keys. I think the issue is one of misuse rather than implementation.

The firmware refusing to let you change the keys is the root of the problem but it's also useful as an anti theft measure when it's not being abused by OEMs. Boot security doesn't depend on that though.

In addition to the above, as an alternative implementation I believe measured boot and a sealed secret is also sufficient to implement boot security without the need for the firmware to manage user provided keys at all.

If the manufacturer wanted to conduct a supply chain attack on you, they wouldn't need secure boot to do it. They could just design an implant of their own using proprietary technology.

So why does the presence of secure boot as a user-controlled feature affect that risk calculation?

> but I don't know how to implement it so it can't be used to lock you out of your own computer.

You probably need Heads with Librem Key, like Purism offers for their laptops.

Because manufacturers aren't trying to add surreptitious implants. They're trying to prevent you installing operating systems other than the one they get a bulk discount if they force you to have.

There was this SixOS presentation[0] 2 months ago of a single man's own distro, among a lot of things he claims that he's created the most secure boot process ever

> On NixOS, either the initrd "secrets" or the software that decrypts them is stored unencrypted on writable media. Ownerbooted sixos closes this loophole without any "trusted computing" voodoo, eliminating all unencrypted storage except for an eeprom whose hardware write-protect pin is connected to ground... coreboot [loads] an immutable pre-kexec kernel from write-protected SPI flash... authenticate the user, decrypt writeable storage, kexec into the post-exec kernel... The speaker runs ownerbooted sixos on his workstations, servers, twelve routers, stockpile of disposable laptops, and on his company's 24-server/768-core buildfarm.

[0] : https://news.ycombinator.com/item?id=42884727

Whatever the intent, the point stands: why would they need secure boot to do that? They could just do it with proprietary controls. So how does the existence of secure boot as a user-controlled feature affect that risk?

The specific proprietary controls you're referring to are called "secure boot".

I think that is a uselessly reductive interpretation of what secure boot is because you could apply the same logic to any security technology. Why should we allow login passwords or user permissions or disk encryption, since those could be used as lock-out technologies by manufacturers, if they just ship them with defaults you can't control?

Manufacturers don't need any user-facing standardized controls to implement lockouts. So the possibility of a feature being used as a lockout shouldn't be a justification for taking away the option of having a user-controlled security feature. Taking it away from users isn't going to stop manufacturers from doing it anyway with proprietary technologies instead.

They aren't doing that either. It's a tiresome point of FUD that comes up in every thread on secure boot.

Because manufacturers do use secure boot to prevent you changing your OS and don't use fingerprint recognition to prevent you selling your device to someone else. If they did the latter, that would also be bad, but they don't.