“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 kernel.org 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.
I also saw “data leak” vulnerability in journalctl and when I check /proc/cpuinfo I see only one core instead of two.
It looks like my machine is compromised.
It behaves weirdly.
I tried to update-grub with “mds=full,nosmt” but I couldn’t.
And here, I found out that there is no need for that, according to you guys.
But how can I have my second core in /proc/cpuinfo and how to make disappear the “data leak” warning in journalctl?
Nice necro ^^
I see two processors (cores or threads ?) on your picture.
What are the CPU specs concerning core/threads ?
You can also list CPUs with “xl top” (aka “xentop”) or “xl vcpu-list”.
I wouldn’t worry too much about the “random: crng init done”, it’s related to the kernel initializing the random number generator. Sometimes it needs more time than usual to initialize.
I don’t remember why exactly, but it had to do with the system not having enough data to produce proper randomness.
@qubean - I think you do not understand what you are seeing.
Your processor has two cores - you see them in /proc/cpuinfo - these
are physical cores on the CPU.
smt is a method by which multiple processing threads can be run at
the same time across those physical cores.
smt is off by default in qubes.
This is why you see only the physical cores in /cpuinfo. This is
exactly what you would expect to see.
As for the “behaves weirdly” I would need far more information to
comment.
So, it is not unusual?
Not really, I’ve seen this warning on several of my machines (physical or virtual), and IN MY CASE, after some research, it was benign.
It’s only a warning after all, and the warning tells you it’s initialized OK, so I don’t see where the problem is.
But I can’t speak about all use cases in the world !!!
Maybe LUKS needs the PRNG ? Don’t know.
My wild guess is that if the PRNG is really needed by LUKS, it would wait for the PRNG to be fully initialized anyways.
What I think about this bug, is that the PRNG takes time to initialize, and reports back on VT1 at the same time the LUKS password is requested, which rightfully freaks the user out ^^
Note those kind of “text spitting” happens often on VT1 (the first text console of a system).
Well, on servers anyways, as it seems “desktop” installs usually block this text spitting on VT1.
The fun thing is you can still type your password and it will work. In this case, humans and computers don’t see the same thing ^^
@unman , should I post my findings on github, to maybe close the bug ?
It’s merely a display problem, not a security concern.
absolutely, and thanks for your input.
Done, no prob, happy to help back !
Moved to User Support
FYI, I don’t have anymore “random: crng init done” string appearing during boot.
I guess it is due to an update in dom0 (I saw something about “kernel” in the update process)
What if smt=off and proc/cpuinfo shows 4 cores, but sensors have temp from 1 to 7, as if SMT is on.
Run xl vcpu-list and check “Affinity” of dom0; if it says 0-7 then you’ve indeed got a problem (I’m assuming that your CPU has 4 SMT-capable cores), but it will probably show something like 0, 2, 4, 6.
Indeed, it shows 0,2,4,6.
What exactly does this mean then?
It means that SMT is off, so no worries.
If SMT was on then Xen would assign dom0 to vcpus 1, 3, 5 and 7 as well, but since it’s off those aren’t available.
