Microarchitectural Data Sampling (MDS) Mitigation
Ross Mcilroy et al. (via Hacker News):
This paper explores speculative side-channel attacks and their implications for programming languages. These attacks leak information through micro-architectural side-channels which we show are not mere bugs, but in fact lie at the foundation of optimization. […] As a result of our work, we now believe that speculative vulnerabilities on today’s hardware defeat all language-enforced confidentiality with no known comprehensive software mitigations, as we have discovered that untrusted code can construct a universal read gadget to read all memory in the same address space through side-channels. In the face of this reality, we have shifted the security model of the Chrome web browser and V8 to process isolation.
Major slowdowns caused by the new Linux 4.20 kernel have been traced to a mitigation for Spectre variant 2 that Linux founder Linus Torvalds now wants restricted.
It’s hard to believe it has now been more than one year since the disclosure of Meltdown and Spectre. There was so much frenzy in the first days and weeks that it has perhaps obscured the fact any solutions we currently have are temporary, barely secure, spackle-everywhere stopgap mitigations, and now that the dust has settled on that, I thought I’d look at what researchers and other contributors have come up with in the last year to provide secure processors – without of course requiring all of us to rewrite all our software from scratch.
Apple (via Benjamin Mayo):
Intel has disclosed vulnerabilities called Microarchitectural Data Sampling (MDS) that apply to desktop and notebook computers with Intel CPUs, including all modern Mac computers.
Although there are no known exploits affecting customers at the time of this writing, customers who believe their computer is at heightened risk of attack can use the Terminal app to enable an additional CPU instruction and disable hyper-threading processing technology, which provides full protection from these security issues.
[…]
Testing conducted by Apple in May 2019 showed as much as a 40 percent reduction in performance with tests that include multithreaded workloads and public benchmarks.
It’s good that there are no known exploits using these techniques, but even if there were, the overwhelming majority of Mac users — almost everyone — would not need to enable this mitigation. These MDS vulnerabilities enable malware on your computer to do bad things. But these vulnerabilities are not ways for malware to get onto your computer.
However, it sounds like the fix is finally a way to work around the hyper-threading bug that can lead to data corruption on my iMac, amongst other Macs.
Previously:
- Mitigating Spectre With Site Isolation in Chrome
- Intel CPU Design Flaw Necessitates Kernel Page Table Isolation
- Bug in Skylake and Kaby Lake Hyper-threading
Update (2019-05-31): Quentin Adam:
FYI, as cloud provider we rawly loss around 25% of CPU performances the lasts 18 months due to different CVE and issues on CPU and mitigation limiting capacity using microcode, so we stuff more CPUs, but prices didn’t go down at all... That’s a kind of upselling. #IntelFail
3 Comments RSS · Twitter
@Michael
Have you learned anything more about the Skylake and Kaby Lake Hyper-threading bugs since your 2017 post? I’m trying to ascertain whether Apple has shipped updated microcode or if my i7-6567U is still affected. While I think I could accept the risk of MDS on my CPU-starved MBP, if data integrity is also on the line then I really have no choice but to disable HT.
(`sysctl machdep.cpu.microcode_version` reports my microcode at version 204 (0xCC), and the Perl script in this Debian mailing list post [1] suggests that it was patched in 0xB9. No guidance on Kaby Lake microcode in that post, though.)
[1] https://lists.debian.org/debian-devel/2017/06/msg00367.html
@Ghost I hadn’t looked into it since Apple told me it would be fixed in High Sierra and it wasn’t. But now (using 10.14.5 now) it looks like my microcode has been updated from 88 to 180. I haven’t see any documentation of what that changes, though.
@Michael
Thanks for your response! I had trouble finding documentation too. I’m hoping that each microcode revision is simply a superset of all the fixes included in prior revisions, but I have no evidence to actually substantiate that. It’s also unclear if the microcode version numbers reported by `sysctl` correspond to Intel’s version numbers, or if they’re instead Apple-specific versions.