3 ms·
For anyone wondering "Why would you boot from an untrusted/compromised server?" or "Isn't this moot? If the server is compromised, it can just send a malicious
by Arch-TK 3y ago
For anyone wondering "Why would you boot from an untrusted/compromised server?" or "Isn't this moot? If the server is compromised, it can just send a malicious binary." the short answer is:
The binary that the shim ends up booting has to be signed by the MOK. So it should continue to provide the same security guarantees whether you're booting from within a compromised network, over HTTP, or if you're booting from a compromised server (even if it's over HTTPS).
It's also important to note that secure boot doesn't prevent downgrades, so the fact that a compromised server could be utilised in a downgrade attack is not relevant. You would need to implement downgrade attack prevention in a more robust way regardless.
That being said, I don't know _why_ the shim needs to support http boot (after all, nothing stops this from being implemented as second local EFI binary which handles it and is signed by the MOK), aside from maybe that it was thought to be a relatively simple feature to implement.