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

[t.lamprecht]

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.

 

[javii]

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]

Found:
https://www.intel.com/content/dam/w...A00233-microcode-update-guidance_05132019.pdf

No patch for Westmere EP-...

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.

 

[guillaume34500]

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,

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]

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]

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

cat /sys/devices/system/cpu/vulnerabilities/mds

Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable

Is this what is expected?

 

[nttec]

is there a way to get the microcode without subscription?

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

 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

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]

is there a way to get the microcode without subscription?

See:
https://forum.proxmox.com/threads/z...-2018-12127-cve-2019-11091.54308/#post-250295
and ensure you run

apt install intel-microcode

after the addition of non-free and an apt update.

 

[t.lamprecht]

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:

Mitigation: Clear CPU buffers; ...

 

[BobhWasatch]

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]

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