[heavyset_go]

Unless your BIOS/UEFI supports full disk encryption unlocking of hardware-encrypted Opal drives, you will always have an unencrypted bootstrap process at early boot from the disk.

That unencrypted bootstrap process can be modified by anyone with access to the disk, physical or remote. Theoretically, someone can inject a keylogger into the process and exfiltrate your encryption key's password, or a process that waits until you're decrypted and exfiltrates your data. It's also a potential vector for ransomware, root/boot kits, etc.

[fsflover]

https://news.ycombinator.com/item?id=44246281

[JCattheATM]

What you've described in that comment is just kind of reinventing the wheel. You're solving the same problem a different way, in a way that has slightly more complexity than just using UEFI and secureboot.

[fsflover]

The main difference is that the user owns the root of trust and doesn't have to blindly trust a (buggy) proprietary software from a commercial company. Also, the community review.

[JCattheATM]

You could still have that with UEFI though.

[fsflover]

But not with Secure Boot AFAIK.

[JCattheATM]

Well, yeah, you could, that was the point of my comment.

Coreboot supports secure boot, so why isn't that sufficient?

[heavyset_go]

Ah, I thought you were replying to the full quote