ZombieLand / RIDL / Fallout (CVE-2018-12126, CVE-2018-12130, CVE-2018-12127, CVE-2019-11091)

t.lamprecht

Proxmox Staff Member
Staff member
Jul 28, 2015
1,388
201
63
South Tyrol/Italy
Is this ok?
The kernel detects that it runs in a VM, where it doesn't know if it runs on a SMT "thread core" or a real, non-SMT shared core, you effectively can fake both for the VM by chaning the CPU setting (socket, core, thread) of the VM. The SMT part is only really relevant for the host.

See:
https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html#mds-system-information

The other part, i.e.,
Vulnerable: Clear CPU buffers attempted
is currently expected for VMs, the issue here is that the CPU would need the 'md_clear' flag to signal the Kernel that the recycled "VERW" instruction does what it should with the new microcode, clear the internal CPU buffers which made this exploit possible. Currently we cannot set the "md_clear" flag for the VM cpu, this will probably be possible in the future. But, AFAICT, that's for cosmetics only, as once "Clear CPU buffers attempted" is shown by the guest OS and the Host OS has new kernel + microcode updates the vmwerv instruction should go through and actually do the correct thing on the host. In other words, the guest OS always tries to call the mitigation instruction, if the host is mitigated then all is well, else it's a no-op, but the guest cannot really tell (yet) what of the two things are happening. I hope I could phrase this somewhat clear.
 
Last edited:

javii

New Member
Feb 27, 2013
16
0
1
The kernel detects that it runs in a VM, where it doesn't know if it runs on a SMT "thread core" or a real, non-SMT shared core, you effectively can fake both for the VM by chaning the CPU setting (socket, core, thread) of the VM. The SMT part is only really relevant for the host.

See:
https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html#mds-system-information

The other part, i.e.,


is currently expected for VMs, the issue here is that the CPU would need the 'md_clear' flag to signal the Kernel that the recycled "vmwerv" instruction does what it should with the new microcode, clear the internal CPU buffers which made this exploit possible. Currently we cannot set the "md_clear" flag for the VM cpu, this will probably be possible in the future. But, AFAICT, that's for cosmetics only, as once "Clear CPU buffers attempted" is shown by the guest OS and the Host OS has new kernel + microcode updates the vmwerv instruction should go through and actually do the correct thing on the host. In other words, the guest OS always tries to call the mitigation instruction, if the host is mitigated then all is well, else it's a no-op, but the guest cannot really tell (yet) what of the two things are happening. I hope I could phrase this somewhat clear.
Thank you!
 

t.lamprecht

Proxmox Staff Member
Staff member
Jul 28, 2015
1,388
201
63
South Tyrol/Italy

guillaume34500

New Member
Sep 24, 2016
8
0
1
31
From the release dates of this model it's a but borderline, but you may not be affected by all the issues here, not sure about the full list of affected models and, AFAICT, different models are affected by a different set of those issues.
Dear,

Code:
CVE-2018-12126 aka 'Fallout, microarchitectural store buffer data sampling (MSBDS)'
* Mitigated according to the /sys interface:  NO  (Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable)
* CPU supports the MD_CLEAR functionality:  NO
* Kernel supports using MD_CLEAR mitigation:  UNKNOWN
* Kernel mitigation is enabled and active:  NO
* SMT is either mitigated or disabled:  NO
> STATUS:  VULNERABLE  (Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable)

CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)'
* Mitigated according to the /sys interface:  NO  (Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable)
* CPU supports the MD_CLEAR functionality:  NO
* Kernel supports using MD_CLEAR mitigation:  UNKNOWN
* Kernel mitigation is enabled and active:  NO
* SMT is either mitigated or disabled:  NO
> STATUS:  VULNERABLE  (Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable)

CVE-2018-12127 aka 'RIDL, microarchitectural load port data sampling (MLPDS)'
* Mitigated according to the /sys interface:  NO  (Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable)
* CPU supports the MD_CLEAR functionality:  NO
* Kernel supports using MD_CLEAR mitigation:  UNKNOWN
* Kernel mitigation is enabled and active:  NO
* SMT is either mitigated or disabled:  NO
> STATUS:  VULNERABLE  (Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable)

CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)'
* Mitigated according to the /sys interface:  NO  (Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable)
* CPU supports the MD_CLEAR functionality:  NO
* Kernel supports using MD_CLEAR mitigation:  UNKNOWN
* Kernel mitigation is enabled and active:  NO
* SMT is either mitigated or disabled:  NO
> STATUS:  VULNERABLE  (Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable)
MD_CLEAR functionality so not Vulnerable ?

Regards
 

t.lamprecht

Proxmox Staff Member
Staff member
Jul 28, 2015
1,388
201
63
South Tyrol/Italy
MD_CLEAR functionality so not Vulnerable ?
If your CPU is affected you're clearly vulnerable, but those checks only check if mitigations are in place, if not vulnerable the mitigations are not needed in the first place - and your CPU model could be old enough to not be vulnerable, emphasis on could as I'm not fully sure, if in doubt ask your HW vendor.
 

oX9ke

New Member
May 15, 2019
7
0
1
44
You do not have a valid support subscription, or do not have it setup, so you cannot access the Enterprise Repository. Either buy and setup a Support Subscription, or setup a repo you can access, i.e., pve-no-subscription (see: https://pve.proxmox.com/wiki/Package_Repositories#_proxmox_ve_no_subscription_repository ) and try again.

No, as you have no valid repo you did not get any upgrade from Proxmox side, so you do not have the new kernel with the mitigations installed. To ensure that this kernel is installed run `pveversion -v`, it shows all installed kernels at the top, and in addition the current running one, there should be a pve-kernel-4.15.18-14-pve kernel in version 4.15.18-39 or later.

Thanks. I did as you suggested and am now getting the following output for
Code:
cat /sys/devices/system/cpu/vulnerabilities/mds
Code:
Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable
Is this what is expected?
 

nttec

Member
Jun 1, 2016
38
0
6
36
is there a way to get the microcode without subscription?


Code:
cat /sys/devices/system/cpu/vulnerabilities/mds
Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled


Code:
 cat /sys/devices/system/cpu/vulnerabilities/*
Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
Mitigation: PTI
Mitigation: Speculative Store Bypass disabled via prctl and seccomp
Mitigation: __user pointer sanitization
Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling


Code:
pveversion -v
proxmox-ve: 5.4-1 (running kernel: 4.15.18-14-pve)
pve-manager: 5.4-5 (running version: 5.4-5/c6fdb264)
pve-kernel-4.15: 5.4-2
pve-kernel-4.15.18-14-pve: 4.15.18-39
pve-kernel-4.15.17-1-pve: 4.15.17-9
corosync: 2.4.4-pve1
criu: 2.11.1-1~bpo90
glusterfs-client: 3.8.8-1
ksm-control-daemon: 1.2-2
libjs-extjs: 6.0.1-2
libpve-access-control: 5.1-9
libpve-apiclient-perl: 2.0-5
libpve-common-perl: 5.0-51
libpve-guest-common-perl: 2.0-20
libpve-http-server-perl: 2.0-13
libpve-storage-perl: 5.0-42
libqb0: 1.0.3-1~bpo9
lvm2: 2.02.168-pve6
lxc-pve: 3.1.0-3
lxcfs: 3.0.3-pve1
novnc-pve: 1.0.0-3
proxmox-widget-toolkit: 1.0-26
pve-cluster: 5.0-37
pve-container: 2.0-37
pve-docs: 5.4-2
pve-edk2-firmware: 1.20190312-1
pve-firewall: 3.0-20
pve-firmware: 2.0-6
pve-ha-manager: 2.0-9
pve-i18n: 1.1-4
pve-libspice-server1: 0.14.1-2
pve-qemu-kvm: 3.0.1-2
pve-xtermjs: 3.12.0-1
qemu-server: 5.0-51
smartmontools: 6.5+svn4324-1
spiceterm: 3.0-5
vncterm: 1.5-3
zfsutils-linux: 0.7.13-pve1~bpo2
 

t.lamprecht

Proxmox Staff Member
Staff member
Jul 28, 2015
1,388
201
63
South Tyrol/Italy

t.lamprecht

Proxmox Staff Member
Staff member
Jul 28, 2015
1,388
201
63
South Tyrol/Italy
Is this what is expected?
Better, but not yet fully, as pointed in various of my posts. Please install the `intel-microcode` package (see one post above) and reboot, then it should show something like:
Code:
Mitigation: Clear CPU buffers; ...
 

BobhWasatch

Member
Mar 16, 2019
58
7
8
57
After aplying new kernel in Proxmox and installing intel-microcode package from debian non-free repo, I get this on the host:
# cat /sys/devices/system/cpu/vulnerabilities/mds
Mitigation: Clear CPU buffers; SMT vulnerable

However in a Centos 7 VM inside this host, with udpated kernel I get this:
# cat /sys/devices/system/cpu/vulnerabilities/mds
Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown

Is this ok?
Thank you in advance. Regards.
Read this:
https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html
 

Hossie

New Member
May 20, 2019
1
0
1
34
I think it's still important to have the qemu patches so that "trusted" VMs are protected.

Ubuntu is patching this, too (Cannot post link as new user, search for "qemu 1:3.1+dfsg-2ubuntu3.1")
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE and Proxmox Mail Gateway. We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get your own in 60 seconds.

Buy now!