#OSSummit: Linux Continues to Pay the Price for CPU Hardware Vulnerabilities
More than a year and a half ago, the world first learned of the Spectre and Meltdown attacks impacting Intel and other CPU vendors. The flood of somewhat related CPU hardware issues has continued since then as operating systems developers, including Linux kernel developers, have raced to keep pace with patching.
In a keynote at the Open Source Summit in San Diego, California on August 22, Greg Kroah-Hartman, who maintains the stable Linux kernel, outlined the many new CPU hardware security challenges that Linux developers have faced in the past year, that extend far beyond just the original Spectre and Meltdown issues.
Back in May 2019, researchers disclosed the MDS set of vulnerabilities impacting Intel and other CPU vendors. The MDS vulnerabilities include multiple specific issues carrying names such as RIDL, Fallout and Zombieload. Kroah-Hartman explained that the MDS issues are yet another class of Spectre and Meltdown related vulnerability found in CPUs.
“All these issues exploit how processors see in the future, so in order to go faster, you have to guess what’s going to happen next,” he explained.
With the MDS vulnerabilities, Kroah-Hartman said that an attacker could potentially read what someone else already did with a CPU and also cross virtual machine boundaries.
“With cloud computing, you’re running untrusted things on different virtual machines and you don’t know who else is running on your machine,” he warned. “This can be a real issue. I can read data from somebody else and somebody else can read your data, and that’s not a good thing.”
More recently, on August 7, researchers disclosed the SWAPGS flaw impacting Intel CPUs. Kroah-Hartman explained that Intel has documented in its patents how speculative execution works. Researchers and academics reading the patents have been going through the specification and have been able to find flaws, which is how SWAPGS was discovered.
“So now you have all these professors out there reading patents, there’s going to be more,” Kroah-Hartman said about CPU vulnerabilities.
From a Linux perspective, Kroah-Hartman said that in order to mitigate the various CPU vulnerabilities, the Linux kernel has had to do more work, flushing memory buffers to reduce risk among other activities. The additional controls that have been in place to mitigate the issues have also had a performance impact on Linux, that varies based on workload. Kroah-Hartman noted that the mitigations have led to a 15% performance impact for his workloads, which include reading email and building new Linux kernels.
With the MDS and SWAPGS issues, he commented that Intel has generally been pretty good about alerting Linux distributions, which is in stark contrast to the original Spectre and Meltdown issues, where communication was less than ideal. With the proper communication, Linux kernel developers are now able to get fixes into the kernel for Intel CPU security issues quickly, but it also mean that users need to stay on top of patching.
Kroah-Hartman said that, on average, there are 22 patches per day made to the stable Linux kernel branch, with all the patches being known bug fixes.
“The kernel community’s mantra is: a bug is a bug, is a bug,” he said. “We fix it, we push it out and we go.”
It’s not always immediately clear whether a given bug fix is a security issue or not. He noted that there have been circumstances where it wasn’t known until months after a patch was integrated into Linux that it was in fact a security issue. Going a step further, Kroah-Hartman said that users should not rely on whether an issue has a Common Vulnerabilities and Exposures (CVE) identifier or not. A CVE is commonly associated to known vulnerabilities, but that’s not always a good indicator, according to Kroah-Hartman. He noted that only a small fraction of vulnerabilities in fact get unique CVE identifiers.
“The goal of the kernel is to paper over the bugs in hardware and make it look like a unified system to users,” he said. “The problem is when the hardware has bugs that breaks the model of how we thought things worked and you can’t really fix it, and we have to do things to work around this problem.”