End-Of-Life hardware in Qubes-certified computers

[nirar50586]

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?

[fsflover]

Here are some relevant posts:

@adw

In light of QSB-081, should the inclusion criteria be expanded to require that the device’s CPU continues to receive microcode updates? Unfortunately, it looks like this would eliminate all but two of the recommended 4.1 models…

@fsflover

@Sven

What about certified hardware?

I guess it should have a disclaimer, otherwise people might be deceived, thinking that it’s more secure than it actually is.

(I still think it’s necessary)

@adw

marmarek says, “Generally, having microcode updates for certified hardware makes sense. But I think in this specific case, it isn’t the end of the world just yet. And we need to change our approach to sys-net/sys-usb anyway (even if we have microcode updates).”

Short list of laptops/desktops that work well with Qubes OS

Will add my 2 cents here, while navigating through XSA/QSB is really not so easy for end users/anybody really, to have a clear view on status of things but added blind faith in protection without proper compartmentalization/prevention hygiene improvements that should be part of Qubes learning curve since meltdown/spectre of 2019 which literally tinted the sky to a constant ever reddish tone since then, which should influence since then Qubes learning curve to be conscious of what is in computer …

[rubberducky1]

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.

[rubberducky1]

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,

GitHub - speed47/spectre-meltdown-checker: Downfall, Zenbleed, ZombieLoad,...

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

[nirar50586]

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?

[adw]

@rubberducky1

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. […]

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. […]