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.