2019-05-14 Advisory: Microarchitectural Data Sampling (MDS) aka "RIDL" aka "Fallout" aka "Zombiload"
This page covers ongoing efforts and may be updated (latest: 2019-07-10).
Similar to the "Meltdown" and "Spectre" and "L1TF" vulnerabilities from January and August 2018, respectively, four new microprocessor flaws have been discovered affecting Intel chip sets. Like with "Meltdown", "Spectre" and "L1TF", these flaws, if exploited by an attacker with the ability to do local code execution on a system, could allow data which is available in various CPU internal buffers to be exposed to unauthorized processes. While difficult to execute, a skilled attacker could use these flaws to read memory from a virtual or containerized instance, or the underlying host system. In fact, that affects Intel-powered devices with local third-party or local user access like, e.g., CERN's Windows Terminal Servers, LXPLUS as well as the CERN OpenStack cloud infrastructure.
Please note that not taking any action is not an option as this will render your device exploitable!
The general strategy for all systems, including hypervisors, is to update the Intel chipset's microcode and operating system to the most recent version:
- For CERN CentOS 7 and SLC 6, fixes are available through the CERN Linux software repositories. A hard reboot is required afterwards (but see the comment below if your run a VM!);
- For virtual machines in the CERN Computer Centre, fixes are available now through the stardard channels (CMF, Linux repos). However, this will only become effective once also the corresponding hypervisors have been updated and rebooted.
- For hypervisors in the CERN Computer Centre, CERN IT has conducted functional and performance tests of the provided fixes (microcode, kernel, "QEMU", "KVM" and "libvirt" libraries). The roll-out is planned for late July 2019 and documented on the Service Status Board. Simultaneous Multi-Threading (SMT) has already been switched off in order to protect against the previous Spectre / Meltdown / L1TF vulnerabilities. Only for LXBATCH, SMT will stay ON as the risk for a timely exploitation are currently deemed to be acceptable for the LXBATCH use case;
- For CERN centrally managed Windows, fixes are ready and have been rolled out with the normal patch cycle;
- Individual, non-CERN managed systems (private or CERN; Windows, Linux or Mac; office PCs, laptops, ...) should be updated using the standard updating mechanisms (Windows upgrade, yum update,...) and subsequently rebooted. In case of multi-user systems, it is advised that SMT shall be switched off --- please note that this comes with a performance penalty.
Checking the status of your system
Recent Linux releases have added an easy way of checking the status of you system concerning CPU related hardware vulnerabilities: special files in /sys/devices/system/cpu/vulnerabilities/. You can easily learn the status of your system by reading these files e.g via "cat". For this vulnerability, you need to look at /sys/devices/system/cpu/vulnerabilities/mds. If you get:
- "No such file or directory": your kernel needs to be updated
- "Vulnerable: Clear CPU buffers attempted, no microcode; ...": your kernel is up-to-date, BUT the microcode is too old. For VMs this means that you need to wait for the hypervisors to be updated and rebooted
- "Mitigation: Clear CPU buffers; ...": your kernel and microcode are up to date
- "...; SMT Host state unknown": This is a VM, if it's running in the CERN Computer Center (standard shared cells), SMT is in fact off
- "...; SMT vulnerable": SMT is enabled on this physical system. For full protection, it would need to be disabled
- "...; SMT mitigated": SMT is not an issue for your CPU
- "...; SMT disabled": SMT is disabled