Iḿ not sure whether this is the right category to post or not. But I’ll try.
The following post is related to this link:
and therein to the section where no help can be offered to a part of Intel CPU users because the tool issued a “no” in both items under “sudo cpu-microcode-info” despite the patch.
Unfortunately, this is the case with one of my computers.
Therefore I looked for an alternative at a company that offers special and especially secure PCs for Qubes. But the CPU installed in the computer there belongs to the same series as the one I have in the said computer.
I wrote to the company and made them aware of this problem and they replied that the update was up to date and that the appropriate microcodes were installed.
How can this be, when according to Qubes-081 there can be no remedy despite the update?
Thanks for the link, I have read it and conclude that it is a very hard way to find the right and at least half way safe Qubes PC.
What just make me wonder is that a company like nitrokey, which supplies very good products, says it has updates for the corresponding CPU, but that this according to sudo-cpu-microcode-info does not lead to any success in eliminating the problem.
Yes, you are right, but reading through the text at the following link, if you get “no” twice when typing “sudo-info-cpu”, then there is no help for fixing the vulnerability…:
I have done some tests with my PC and there are some inconsistencies.
On the one hand, “sudo-cpu-microcode-info” gives “no” for everything according to the mentioned link. So there is no workaround with that.
This coincides with the fact that there is no corresponding microcode listed under /lib/firmware/intel-ucode, despite the latest Qubes 4.1.1 version. There is also no matching microcode on the matching Intel page:
On the other hand: If I run lscpu, it outputs (among other things) “not affected” for “Vulnerability Mmio Stale Data”, although according to XSA-404 all Intel CPUs should be affected.
How does all this fit together?
Since the Nitro PC processor also belongs to the same CPU family as mine, the question is whether it can be the same here.
First. Nitrokey doesn’t make CPUs nor chipsets. It is important to know what it is. For x230/t430/w530/t530/we are talking about ivy bridge.
And those are not vulnerable. When looking at Intel, they provide information for non EOL products nor microcode updates for them, which is confusing but doesn’t help understanding the issue.
I would invite you to reply and quote parts on referred article to clarify pieces needing more information.
As I had written above, the company had answered me the same. After running sudo cpu-microcode-info I had received a “no” result for both 20220510 update available and update installed in all cases.
I will go through the kernel report again in detail.
@Ionixx have you found a way to MMIO stale data mitigation?
I happen to use an NitroPC too and found this thread. My Qubes 4.1 is up to date and running Xen 4.14.5-7.
sudo cpu-microcode-info shows that loaded microcode version is 000000f0 and 20220510 update is available (yes) and installed (yes).
However lscpu shows vulnerable to MMIO stale data (“Clear CPU buffers attempted, no microcode; SMT Host state unknown”).
FWIW for “srbds” I read “Unknown: Dependent on hypervisor status” which is beyond my non-expert knowledge of Qubes OS. So, any comment on that would be very welcome (or I can ask in another thread?)
no, I don’t have a definite answer to this unresolved question yet. I haven’t gotten the Nitro PC yet because I don’t think the company’s answer is logical. I only have a computer of the same series. For this one I can’t give an all-clear regarding the information under cpu-microcode-info. Therefore, I use it only very limited and switch to safe models.
Therefore I cannot offer a solution to the problem. Only Intel can do that by providing patches.
The question to what extent one can become a victim of one of the unpatched attacks is very difficult to answer, because every user has to define his own threat level for himself. An “average” user will probably rarely be affected. For high security users like whistleblowers, journalists or people who have to fear censorship and persecution, on the other hand, it is very important to think very carefully about what they do on their PC, how, when and with what means.
To answer your detail questions, I recommend the following link:
It is a complex matter indeed and I don’t think there are any really safe models. I suppose the only way to mitigate the issues is to have a proper update through Xen and TemplateVM microcode and kernel.
fwiw Librem 14 has “yes” for all six items in cpu-microcode-info and either “not affected” or “Mitigation” for all items except “Mimio stale data” which shows “Vulnerable” in lscpu. {and 72 Flags}
Cordial: The Librem 14 laptop uses the I7-10710 U processor, while the Nitro PC uses the I7-10510 U. Both belong to the Comet Lake series. How can it be then that more security patches for the microcode are supposed to be available for the Librem 14 than for the Nitro PC?
And how can it be (see my first post at the beginning) that no solution is seen on the Qubes OS page for these machines, but the manufacturers provide one?
did you guys ever figure this out? based on using terminal it says I have 20220510 installed but according to here thats outdated for my processor and for the life of me I cant figure out how to update in on Qubes in any way I’ve tried.
At certain point in time I noticed that a mitigation for MMIO actually started to show up in the list of CPU vulnerabilities. So, with the same version you have installed, I see nothing marked as vulnerable. The only “Unknown” is SRBDS, which I still have no idea how to check: