Qubes OS should not certify insecure and ancient hardware

[anon39129773]

@apparatus

It could be a widespread attack, not only a targeted one.
And not in every case gaining the physical access to the machine is easier than getting the vendor keys and access. Especially if the attacker is a state that can easily get the keys from the vendor.

That is true and again, if that is realistically within your threat model, then act accordingly. That is not the point of my suggestion though, please refer to the last two paragraphs of my previous post.

@apparatus

It’s not enough to protect the user from the attacker with physical access by having only Intel Boot Guard

Of course, I just only mentioned Intel BootGuard only for simplicity’s sake. Other factors are important if your threat model involves attackers trying to get physical access. DRAM memory encryprion, DMA protection, pre-boot DMA protection, firmware rollback protection, AEM and others.

@apparatus

This can be protected by TrenchBoot, but it’s not released yet.

Trenchboot can already be used as the AEM provider in Qubes using Intel or AMD CPUs but only on legacy boot. They are still working on UEFI compatibility and upstreaming their changes.

@apparatus

So is the only hardware that should be certified right now is the one that has unfused Intel Boot Guard so user can use their own key and use Heads?

I didn’t say that. The majority of users do not have state actors as their threat model and would not require unfused Intel BootGuard. Again, referring to my previous post, my suggestions are for providing reasonable security for the majority of users with an average threat model. There is a discussion about flaws with Heads here.

I don’t think Heads is the way to go. When Qubes supports Secure Boot and TrenchBoot supports UEFI and upstreams it to Qubes. Combining this with hardware that implements HSI:2 or above, that would be the ideal setup for average users imo.