[mormegil]

Which is strange because secure boot should be useful in _exactly_ the situation you don't have physical control of the HW, shouldn't it? I guess the threat model for a common not-that-important company does not include evil data center (and it's dubious if SecureBoot would protect you in reality), but wasn't that one of the motivations?

[ChocolateGod]

Well you can tie it to TPM to store your encryption key which should only produce the key when the boot parameters match the key. This is what Windows already does but its not fully supported under Linux and somewhat insecure as you can't encrypt the initramfs (so someone can infect boot process there instead).

[vbezhenar]

There are ways to solve that issue. But I think that you're correct, pinpointing the core issue with popular Linux distributions. It doesn't have to be this way, though.

1. You can sign and verify initramfs, it's supported by bootloaders.

2. You can merge kernel and initramfs into UKI and sign the whole image.

I don't know why that's not implemented.

[the8472]

With a UKI the initramfs gets signed too, doesn't it?

[michaelt]

> Which is strange because secure boot should be useful in _exactly_ the situation you don't have physical control of the HW, shouldn't it?

One of the ways you can introduce your own signing key is as a Machine Owner Key, using the "MOK Manager"

But a design goal of this software was: We don't want malware with root to be able to introduce a MOK without the user's consent, as then the malware could sign itself. So "MOK Manager" was deliberately designed to require keyboard-and-mouse interaction, early in boot before the network has been brought up.

Of course if your server has a KVM attached, you can still do this remotely, I guess.

[bravetraveler]

Aye, though an evil maid has higher barriers and more paperwork in a DC.

I hesitate based on that mitigation and the untold operational pain. Sometimes it's worth it, other times it isn't.