Smt isn’t off by default although smt=off is set in the grub

Continuing the discussion from [SOLVED] Unable to passthrough audio device to sys-audio:

Oh damn, another hardware vuln that impact perfs … Funny, by default RedHat does not use “nosmt” to not disable HyperThreading ! But on Qubes it seems required to protect from rogue domains …
If it’s not documented, create or edit the doc, really ! Maybe in a GRUB page containing all the possible options ? Or in a page “Mitigating the know vulns” ?

Well I don’t know why it’s not the 1st § of How to use PCI devices, maybe it’s the way Qubes handles it ? Strange, as said passing to pciback early avoids many glitches, but there may be a reason, I dunno.
Anyways, same as above, you should edit the doc ! ^^

Me neither, only used it a couple times, but for simple things it’s really easy and boils down to : fork a project in your space, edit files, propose change.

“A minute ago I discovered that mds=full,nosmt had to be added to grub for those having mds vulnerability which could cause data leak. Also, nowhere documented as far as I know.”

Not needed.

mds=full is the default (check doc), smt is globally disabled in Qubes OS (see /etc/default/grub). So already mitigated by default in Qubes.

Then why when executed

sudo dmesg | grep -i vuln

I got the only entry about smt wasn’t disabled? After set it in grub manually as described, no more “vuln” entries in dmesg.

Here’s earlier entry from journalctl:

`-- Reboot –

Feb 28 13:32:35 dom0 kernel:` MDS CPU bug present and SMT on, data leak possible. See MDS - Microarchitectural Data Sampling — The Linux Kernel documentation for more details.

I noticed that message as well, but it doesn’t make sense. Possibly a kernel bug.

If you check the sys vulns fs you’ll also notice the kernel saying “unsure about mds mitigation”.

You can also check whether smt is enabled via cat /proc/cpuinfo | grep smt or just count the number of cores it shows.

Thanks, good to know. Already adding it manually to grub saved me time and/or gave me (even false, but anyway) sense of security.