According to docs the 2 possible values for /sys/devices/system/cpu/vulnerabilities/l1tf are ‘Not affected’ and ‘Mitigation: PTE Inversion’. One one of my systems I see the second value. However on another system the value is ‘Vulnearable’:
# dmesg | grep -i l1tf
0.020108] Spectre V2 : System has more than MAX_PA/2 memory. **L1TF mitigation not effective.**
# find /sys/devices/system/cpu/vulnerabilities/ -type f -print -exec /usr/bin/cat '{}' \;
/sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full generic retpoline, IBPB, IBRS_FW
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
Mitigation: Speculative Store Bypass disabled via prctl and seccomp
**/sys/devices/system/cpu/vulnerabilities/l1tf
Vulnerable**
/sys/devices/system/cpu/vulnerabilities/spectre_v1
Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/meltdown
Mitigation: PTI
But the docs say nothing about disabling of virtualization. They speak of disabling of SMT and “The Intel implementation of SMT is called HyperThreading”
I disabled “Intel virtualization technology” in BIOS CPU setting. The only thing that changed is that now I see
dmesg | grep -i kvm
9.617824] kvm: disabled by bios
However the “L1TF mitigation not effective” and “Vulnerable” remain.
Also trying to run a VM guest now fails with:
Error starting domain: unsupported configuration: Domain requires KVM, but it is not available. Check that virtualization is enabled in the host BIOS, and host configuration is setup to load the kvm modules.
Traceback (most recent call last):
File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 89, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 125, in tmpcb
callback(*args, **kwargs)
File “/usr/share/virt-manager/virtManager/libvirtobject.py”, line 82, in newfn
ret = fn(self, *args, **kwargs)
File “/usr/share/virt-manager/virtManager/domain.py”, line 1508, in startup
self._backend.create()
File “/usr/lib64/python3.6/site-packages/libvirt.py”, line 1069, in create
if ret == -1: raise libvirtError (‘virDomainCreate() failed’, dom=self)
libvirt.libvirtError: unsupported configuration: Domain requires KVM, but it is not available. Check that virtualization is enabled in the host BIOS, and host configuration is setup to load the kvm modules.
zypper se -si ucode-intel microcode
S | Name | Type | Version | Arch | Repository
--+-------------+---------+----------------------+--------+--------------------------
i | ucode-intel | package | 20180807-lp150.2.7.1 | x86_64 | openSUSE-Leap-15.0-Update
[QUOTE=malcolmlewis;2877932]Hi
See: https://www.suse.com/support/kb/doc/?id=7023077
[/quote]
Yes, I have already seen this before opening the thread. It seems to duplicate part of the kernel docs. One thing which caught my eye:
kvm-intel.enable_ept=0
…
SUSE recommends to leave this enabled, but instead use the L1D cache flush and SMT mitigations.
According to kernel docs this gives maximum protection without having to disable SMT, i.e. it looks better performance-wise without security drawbacks. So why does SUSE recommend against it?
FWIW I tried using this option and also l1tf=full,force (in separate boots) but none of them changed anything - still vulnerable.
So did the microcode update occur?
How do I know? I don’t know if that is related but the initial line of dmesg shows:
0.000000] microcode: microcode updated early to revision 0x20, date = 2018-04-10
I don’t have a swap partition. Does it still relate to me in any way?
ETA: Just found that Linus says that “[MAX_PA/2 worth of memory] is very unlikely to happen on real systems.” Strangely the dmesg line says that this is exactly the case (the system has 32GB of RAM, the maximum which the CPU and the MB support).
