Spectre V2 : System has more than MAX_PA/2 memory. L1TF mitigation not effective.

English Install/Boot/Login
1

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
  • Running kernel-default-4.12.14-lp150.12.16.1.x86_64

Even after disabling hyperthreading from BIOS nothing changes.

What to do?

2

Hi
It’s not hyperthreading to disable in the BIOS but virtualization…

3

But the docs say nothing about disabling of virtualization. They speak of disabling of SMT and “The Intel implementation of SMT is called HyperThreading”

4

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.

5

Hi
See: Security Vulnerability: "L1 Terminal Fault" (L1TF) aka CVE-2018-3615, CVE-2018-3620 & CVE-2018-3646. | Support | SUSE

So did the microcode update occur?

What is the cpu(s) in question?


lscpu | egrep "Model name:|Flags"

Model name:          Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts flush_l1d


BEFORE:
dmesg | grep -i l1tf

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
Mitigation: PTE Inversion; VMX: SMT vulnerable, L1D conditional cache flushes

/sys/devices/system/cpu/vulnerabilities/spectre_v1
Mitigation: __user pointer sanitization

/sys/devices/system/cpu/vulnerabilities/meltdown
Mitigation: PTI

AFTER:

dmesg | grep -i l1tf

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
Mitigation: PTE Inversion

/sys/devices/system/cpu/vulnerabilities/spectre_v1
Mitigation: __user pointer sanitization

/sys/devices/system/cpu/vulnerabilities/meltdown
Mitigation: PTI



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
6

Hi
Re-enable then… :wink:

I see this popped up on the ML as well…
https://lists.opensuse.org/opensuse-factory/2018-08/msg00216.html

7

[QUOTE=malcolmlewis;2877932]Hi
See: Security Vulnerability: "L1 Terminal Fault" (L1TF) aka CVE-2018-3615, CVE-2018-3620 & CVE-2018-3646. | Support | SUSE
[/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

The CPU info shows the “flush_l1d” flag:


# lscpu | egrep "Model name:|Flags"
Model name:          Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts flush_l1d
# zypper se -si ucode-intel microcode
Loading repository data...
Reading installed packages...

S  | Name        | Type    | Version              | Arch   | Repository
---+-------------+---------+----------------------+--------+--------------
i+ | ucode-intel | package | 20180807-lp150.2.7.1 | x86_64 | *Update (OSS)



BEFORE:
...

AFTER:

What did you do between before and after?

[QUOTE=malcolmlewis;2877933]
I see this popped up on the ML as well…
https://lists.opensuse.org/opensuse-factory/2018-08/msg00216.html[/QUOTE]

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).

8

Hi
You would need to ask the SUSE/openSUSE kernel devs about the boot option and also the warning, suggest a bug report with your findings.

The before and after was disabling/enabling virtualization in the BIOS…

Might be the RAM size then, don’t see it here with 8GB…

9

Thank you for your help.

OK. Let’s see what they say:

https://bugzilla.opensuse.org/show_bug.cgi?id=1105536