End-Of-Life hardware in Qubes-certified computers

I noticed some Qubes-certified computers have end of life hardwares. for example the cpu of Insurgo PrivacyBeast X230 is Intel® Core™ i7-3520M Processor whose launch year is 2012 and is already in End of Servicing Lifetime status. This means the cpu cannot receive securitys update from Intel any more. Does this mean the cpu is not secure in case there’s some kind of flaw that need microcode/firmware update?(like side channel attack) Will that make Qubes running on it unsafe?

1 Like

Here are some relevant posts:

(I still think it’s necessary)

1 Like

You are correct. End of life CPU’s will no longer receive security updates. The CPU would not be secure in the case of a new flaw or a flaw that is being exploited. I would not be sure if Qubes could isolate those types of attacks. Since the CPU is compromised it would mean they have full control. Therefore any OS would be unsafe.

On the other hand if some community has a bios/firmware update for your old cpu to bring it up to date that could help. But then you would have to trust the community fix is a proper fix.

In my personal opinion I would no longer use the computer if its no longer receiving security updates because its end of life. Sell it and buy a new one or a used one that still provides support. However the CPU you mention I believe is ok.

You can verify your cpu is vulnerable with the following popular script,

Just run it from a live linux boot OS as you may have problems running it from Xen (QubesOS).

1 Like

Thank you for your reply. After conducting some research and searching the forum, I have learned that a system with secure boot, such as one that uses the HEADS firmware, is a good alternative to AEM as it has SRTM to detect firmware changes. However, I have some additional questions:

1 Does Trenchboot AEM support secure boot? Can Trenchboot be used with HEADS?
2 Is there a way to protect SMM on Qubes, such as through paging protection or SMM supervision?
3 Can we use runtime integrity inspection on Qubes with trenchboot now?

This is often spelled out explicitly in QSBs. For example, here’s an excerpt from QSB-081, which was mentioned above:

[…] If both columns have “no” values, then this CPU
remains vulnerable, and there is no known mitigation available. If your
system has such a CPU, then installing The Xen packages listed in the
“user action required” section above is not expected to mitigate the
problem described in this bulletin. Unfortunately, there is simply
nothing we can do for these CPUs in terms of patching unless we receive
a fix from Intel or receive new information about which CPUs are
affected. […]

As another, more recent, example, here’s an excerpt from QSB-093:

[…] Therefore, until the relevant OEM, ODM, or MB provides
a suitable BIOS or (U)EFI update for a system, the package updates
listed above will not be sufficient to address CVE-2023-20569/XSA-434 on
that system. […]


I doubt it has real SRTM because the boot block is not protected by Boot Guard

Even if it would have been signed … keys get lost.