Comment by exceptione

"on a system not configured for boot security, you get no boot security" is indeed correct. If you care about boot security, your local platform doesn't give you the chance to boot custom kernels and not passing secure boot doesn't give you decryption keys.

There are multiple possible configurations. Only the most basic will permit an arbitrary payload as you describe.

I've never been entirely clear about the security model when the signed shim is permitted. I assume I'm missing some nuance.

Disk encryption alone won't protect you from either persistent malware (remote) or evil maids (local).

> The only boot security real users need is disk encryption.

Which becomes easy to bypass without boot security. If an adversary can modify code that executes in the boot process, they can steal your keys.

> signed shim

How would they sign such a shim without my keys? I don't leave Microsoft keys enrolled on my laptop.

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.

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

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?

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

That's almost entirely correct, with one exception:

> It fits the personality profile of not wanting to learn new things.

'systemd haters' learn a lot. They learn how to write manual boot scripts, set up mdev instead of udev, compile their own kernel, install their own u-boot or coreboot, strip binary blobs, etc. etc. They know MORE than the average systemd guy. They just don't want to learn systemd.

Isn't the whole purpose of systemd to ease and automate administration and configuration, so the user need not care? Doesn't that imply that systemd admins/users know LESS?

----

Now let me make my own characterization of 'systemd enthusiasts'.

These people are overworked sysadmins that hate manual configuration. They want it easy, everything automated, they want to not care about it, they want the distro to auto-do everything and not even ask, they want less admin work. Systemd does all these things for them and they are in heaven. They're so enthusiastic that they feel we should all be one big happy family under the systemd umbrella.

But they fail too see that no company or manager will tolerate people that are _not_ overworked.

When something becomes automated, people previously doing the manual job are fired. A 10 people non-systemd team that works day-and-night to set manually up boot, mounts, network, services, cron, backups, logs, etc., as soon as systemd automates the work, will be cut down to just one guy (or less) and he will still work day-and-night, same as before, doing the work of the entire team. And he won't be able to take break because there's nobody left to replace him.

They also fail to see that resilience comes from diversity. Uniformity, systems where software is identical, updates are identical, configuration is identical, permissions are identical, etc., will also fail identically and probably at the same time, and will be hacked identically and at the same time (by automated bots/tools).

> frozen in time on some ancient version.

Yeah that's a feature of Debian stable

They very much did not for me. I beat things into shape with sbctl but it was very much an uphill battle.

idk why Arch seems allergic to packaging shim-signed (it's an AUR, why would I trust such a key component to essentialy a stranger?), but here we are I guess.