yea the MMIO vulnerability listed in Dom0 terminal is what made me start looking around. Strangely is Dom0 it list the vulnerability but if you run terminal in a template VM it’s marked as mitigated. Super confusing why microcode mitigations would be different between VM’s. I would think the mitigations would be most important in dom0. Can you run “lscpu” in both a template VM terminal and a Dom0 terminal and let me know if the MMIO vulnerability is mitigated for you in both?
This part I did figure out, it list 20220510 package as both update available and updated which confused me into thinking 20220510 was the update that was installed and loaded. It actually isn’t, it’s the last update package that was loaded. what it is saying is that 20220510 did/does have an updated available in the first column and the 2nd column is confirming if that update was installed or not. Only the “loaded microcode version” column shows the updated info from the current microcode package. It would have been less confusing if the first column had 20220510 and if it had an updated available, and the second column with the new update package 20230808 and that it was installed along with showing the current microcode version.
from all the research I’ve done I’m positive I have the current microcode now but for some weird reason Dom0 doesn’t show the mitigations for MMIO which the microcode updates did address in the past already, I still don’t know why, I put up a post and waiting on feedback.
yea the MMIO vulnerability listed in Dom0 terminal is what made me start looking around. Strangely is Dom0 it list the vulnerability but if you run terminal in a template VM it’s marked as mitigated.
Here it shows in dom0 and in domUs as mitigated.
from all the research I’ve done I’m positive I have the current microcode now but for some weird reason Dom0 doesn’t show the mitigations for MMIO which the microcode updates did address in the past already, I still don’t know why, I put up a post and waiting on feedback.
Maybe the available microcode still hasn’t reached the Fedora repos from which dom0 updates.
In case your computer is different, I would suggest that you open a separate thread with title focused on your system specifics. Ideally, you could also open an issue on GitHub, if you are confident this is something that can be fixed by Qubes OS’s developers.
I’m not sure the brand/PC has any impact on this topic at all. It’s included in the title but other than that’s there’s little to no relevance to the topic. He’s asking about microcode mitigations which are not PC brand/model specific rather whole groups of Intel processor families and can be updated outside of the control of Nitro key at all. He also had questions about MMIO vulns showing, which is a question I have as well as both the processor he mentioned and mine DO have microcode updates to mitigate this issue and shouldn’t be showing on lscpu.
The i7-10510U cpu in his devices (CPUID 806EC) can be found in this chart previously linked. The MMIO vuln he had quesitons about is INTEL-SA-00615 by following that chart linked (ctrl+f 806EC) and scrolling over to the INTEL-SA-00615 column you can see this issue on his processor WAS mitigated with a microcode update. He should not be getting that vuln message in Qubes. You said your Nitro is a i7-10610U, which is also cpuid 806EC family abbreviation CML-U62. You reported a microcode version 000000f0this isn’t correct for your machine either you should have 000000f8 as your newest microcode.
I’m not sure the brand/PC has any impact on this topic at all. It’s included in the title but other than that’s there’s little to no relevance to the topic.
I am not arguing or discussing how others put their questions. I have simply suggested that you open a separate thread/issue for your specific model for your own good, unless you expect that people will look for your specific questions in a thread with title which says something else. It’s up to you. Generally, staying on topic is helpful for present and future readers, and considered good netiquette.
You reported a microcode version 000000f0this isn’t correct for your machine either you should have 000000f8 as your newest microcode.
As of today, it is 000000f8.
Re. your earlier:
Super confusing why microcode mitigations would be different between VM’s.
In Qubes 4.2.0, dom0 uses Fedora 37. If your VM template is Fedora 38 it may include newer packages, hence the difference. Perhaps the proper way to address this issue is to report it upstream (to Red Hat), so they can make microcode updates for your CPU available in Fedora 37.
The spec-ctrl=unpriv-mmio option should load the mitigation from Xen using the provided intel microcode.
In configurations where less privileged domains have MMIO access to
buggy endpoints, spec-ctrl=unpriv-mmio can be enabled which will cause
Xen to mitigate cross-domain fill buffer leakage, and extend SRBDS
protections to protect RNG data from leakage.
The unpriv-mmio= boolean indicates whether the system has (or will have) less than fully privileged domains granted access to MMIO devices. By default, this option is disabled. If enabled, Xen will use the FB_CLEAR and/or SRBDS_CTRL functionality available in the Intel May 2022 microcode release to mitigate cross-domain leakage of data via the MMIO Stale Data vulnerabilities.
The microcode to mitigate this issue is available in both version, which is also installed, as the OP stated in a previous post this question is still unresolved for them. I’m not asking a new question I’m continuing the same discussion and providing my own context on my processor and Qubes which is identical to the issue he has and is applicable to this topic. Even though we have different processor we both have the same mitigation update for this issue for our respective processors/family. What isn’t applicable to the topic at all is the brand. I personally dont see an etiquette issue with adding additional context to the same topic issue. Not trying to be confrontational just don’t agree with the assessment.
He left this post thinking that the only way to fix this issue is for Intel to provide updates and therefore doesnt want to use the PC for higher threat needs and also left not trusting Nitro even though what they told him is correct that the microcode on their machines to mitigate that issue is installed. Intel did provided the microcode for this that is applicable to his processor and it is available in both version of Fedora so that should have no impact. I truthfully dont think it has anything to do with his microcode being out of date as being the reason dom0 is return vuln. Likely his microcode is fully up to date just like mine and there’s something weird going on still reporting vuln, Ive seen his post about it along with another which none of them finished with a clear answer on why Dom0 is returning these vuln even though the microcode to mitigate is up to date and installed. Like him I havent seen anything that should assure someone that the microcode vulns show when pulling cpu-microcode-info is not something to worry about even when the processors in question have a confirmed mitigation for it and you can confirm it’s installed. It could be benign but it would still be nice to have a solid answer on it. I’m glad yours doesnt return it but that doesn’t seem to universal. The fact that both OP and you have the exact same family processor therefore the exact same microcode mitigations and that his returns vuln and yours doesn’t would suggest it has nothing to do about a microcode being needed by either Intel or Redhat and more towards some kind of specific configuration issue within Qubes or some conflict that is returning untrue results out of lscpu. Like i said i’ve found at least 3 cases and I’m sure there could be more as people dont often check their microcode info. I’m trying to help answer his question as much as mine.
I have no idea about this, I did not go any further on the subject.
In your xl dmesg logs, I see this SRBDS_CTRL part within Speculative mitigation facilities that was quoted in one of the links I provided, but I don’t see the other one (FB_CLEAR).
Also, I’m not sure why and where the difference is, but I have some microcode lines like this in mine, but you don’t have anything similar in yours:
(XEN) microcode: CPU2 updated from revision 0x22 to 0x32, date = 2023-06-07
>>> What it does
***************************************************************************
Deploy an Intel microcode. This tool is obsolete and the microcode is the
subject to be distributed via kernel-firmware, however Intel still does not
supply the microcode in a form consumable by the Linux's microcode driver. So
that this tool transform Intel's microcode as well as deploy it.
looks like that git is legacy and that microcodes on it stopped being updated in 2019 after looking into it further and they are done via kernel now, which makes sense as if they werent QSB-098 wouldn’t make any sense. Still interesting to see they used to do it all manually, maybe they still do but with Kernel stuff that’s over my head.
I saw something similar to yours when I was first researching how to confirm my microcode was up to date and if my cpu was effected by certain vulns. I remember trying to get mine to show the info lines you’re referring to and I couldn’t and went down another path, so this could definitely be a clue.
I’m really starting to think this issue DOES have something to do with underlying issue that resulted in QSB-098 and it’s possible the fix is not being applied correctly to all machines. In that thread there is also another user who shows no evidence on microcode in his xl dmesg…
I did try just now to regenerate Dracut but no success.
brendanhoar
21d
Is there an order of operations necessary to be sure microcode is loaded after this fix was deployed?
On a fresh R4.2, I have installed kernel-latest (6.6.2-1) and dracut 059-5.fc37, but I think I installed kernel latest before performing the update on dom0 that brought in the new dracut version.
I do not see any evidence of microcode loading in xl dmesg or linux dmesg/linux journalctl output.
--
apparatus
21d
I don’t know how to check it but you can regenerate initramfs just in case:
sudo dracut --regenerate-all --force