I believe not. Even with full disk encryption, you need an unencrypted bootloader after uefi to decrypt the disk.

https://security.stackexchange.com/questions/267222/full-dis...

So, there are two scenarios here.

First, PC with FDE + normal boot gets stolen. The attacker cannot get the data without the password, so it's safe.

Second, unattended FDE + normal boot PC gets tampered with. Attacker manipulates the bootloader. Unsuspecting user later boots the tampered PC, unlocks the FDE, gets owned.

The second case requires a professional, dedicated attacker. I use TPM with Heads and a hardware key to protect myself against it. It will notify me if the boot partition or BIOS are tampered with.

As an advantage, all relevant code running on my computer is FLOSS and auditable, unlike the Secure Boot and UEFI.

That's a cool setup! I didn't know about Heads.

And yes, getting back to the original topic, I believe that against petty criminals, even a full disk encryption is plenty defense. They won't go about installing anything to the EFI partition just to get to the data.

This Coreboot + Heads setup I'd trust to protect against even the more involved.

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.

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.

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.

You could still have that with UEFI though.

But not with Secure Boot AFAIK.

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

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

Secure Boot is closed and not auditable.

Not so, the reference implementation is open source and incorporated into Coreboot, for a long time now.

The reference implementation is not the same as knowing which code runs on "your" hardware and having all keys from "your" hardware. If you are protected by a steel door but you don't have the keys, you are not safe, you are imprisoned.

This seems like a ridiculous argument. There is a fully source open source secure boot implementation, that if you have concerns about it you can fully audit, just as you can fully audit your current setup if you wanted to - but almost certainly have not.

So you are suggesting me to audit an implementation which I do not necessarily run and there's no way to know if I do. What's the point? How will it help?

The code running on my hardware is open, so anybody from the community can audit it and I have a possibility to verify that this is what I run at least by reflashing it. And I did reflash it. This approach is getting more reliable with more software becoming reproducible.

> So you are suggesting me to audit an implementation which I do not necessarily run and there's no way to know if I do. What's the point? How will it help?

No, I'm pointing out your, what seems to fundamentally be contrarian, alternative method that you are preferring because it is 'open', is no more secure than the coreboot secureboot implementation. Your concern seems to be based on the idea that the coreboot secureboot implemetnation could have sus code in their, but that is equally true for your heads setup. Unless you audit both, or pay to have both audited, either could have problem code.

Your position is an irrational inconsistency.

> The code running on my hardware is open, so anybody from the community can audit it and I have a possibility to verify that this is what I run at least by reflashing it. And I did reflash it. This approach is getting more reliable with more software becoming reproducible.

This is equally true for coreboot.

Can I compile coreboot with Secure Boot from source and reflash my UEFI/BIOS with it? If yes, then you have a point. I would appreciate the corresponding link to the source and supported devices.

Yes, you can, as long as you have supported hardware.

Here is there list of supported hardware: https://doc.coreboot.org/mainboard/index.html

Also, heads seems to use coreboot also.

Thanks, I already know where the coreboot source is (and I'm already using it with Heads). Concerning Secure Boot, I only found this (emphasis mine):

> soc/amd/common/block/psp: Add platform secure boot support

>

> Add Platform Secure Boot (PSB) enablement via the PSP if it is not already enabled. Upon receiving psb command, PSP will program PSB fuses as long as BIOS signing key token is valid. Refer to the AMD PSB user guide doc# 56654, Revision# 1.00. Unfortunately this document is only available with NDA customers

I guess I misunderstood your request. This[1] and this[2] should be what you are looking for.

[1] https://doc.coreboot.org/security/vboot/index.html

[2] https://github.com/tianocore/edk2

I found no installable code for Secure Boot itself in your links.

That wasn't what you asked for, and I've given you more than enough links for you to find your way to installing it if you wanted to play with it.

If you want something that will hold your hand a little more, then one of the downstream projects might be a better fit.

I'm satisfied I've backed up my points though.

>> I found no installable code for Secure Boot itself in your links.

> That wasn't what you asked for

Here's a quote from my earlier comment:

>> Can I compile coreboot with Secure Boot from source and reflash my UEFI/BIOS with it?

I don't see how I could formulate it better. You seem to evade the actual answer. I'll continue to think this is impossible.

I'm not avoiding the answer, and I've answered your question more than adequately. It seems you want hand holding each step along the way. Are you perhaps unaware that the coreboot implementation is called verified boot rather than secure boot?

I've shown it's possible to flash hardware and have an entirely open source and auditable secure boot implementation which is better than your current solution in a number of ways. That was all I had a burden to prove, and I've met it.

If you want further help or convincing, I'd suggest interacting with an AI to get answers to your questions.

Ah, I thought you were replying to the full quote