Hyperthreading disabled is no longer a sure fire way to protect yourself if you’re on a older Intel architecture.
Am I affected if SMT (hyperthreading) is disabled?
Yes. Our cross-core attack does not rely on SMT. In fact, as you can see in Table 2, our attack works on an Intel Xeon E3-1220V6 (Kaby Lake) CPU which does not support SMT at all.
Mitigation on RDRAND will cost you 97% of your performance for that operation according to Phoronix:
Intel only applied the mitigation to harden a small number of security-critical instructions, specifically RDRAND, RDSEED, and EGETKEY (a leaf of the ENCLU instruction). This means that output from any other instruction (e.g., RDMSR) that issues offcore requests can be still leaked across CPU cores.
Since I’ve never heard of “phoronix” (don’t judge), I went looking for a more well-known source, like ZDnet
MDS attacks target user data while in a “transient” state, as it’s being processed inside the CPU and its many data-caching systems.
More specifically, CrossTalk attacks data while it’s being processed by the CPU’s Line Fill Buffer (LBF), one of these aforementioned CPU cache systems.
According to the VUSec team, the LBF cache actually works with a previously undocumented memory “staging buffer” that is shared by all CPU cores
No information on what needs to occur for this attack to occur (ex. administrative privileges on a system, or whether a simple website can inject code onto the system and perform this attack), so I’ll hold off on worrying until more information comes out.
That should be par for the course for home users with these vulnerabilities. We normally aren’t running VMs that random people have access to and other places where this really matters.
Its actually more annoying then worrying IMO, because my CPU is actually getting slower as the microcode updates get rolled out.
At this point I’m amazed that the hardware works at all.
Given all of the hardware problems we know so far, it’s probably not that insane to assume that some of the effects of those exploits could occur on accident during normal operation… right?
Also I bought intel based laptop ~8 months ago. I’ll have to replace it sooner than I thought if I’ll update the ucode…
But before you could feel fairly safe if you ran a binary of shady origins in a vm without network access, you’ll just dispose of the VM later, now you have to dispose the host OS as well.
The hell of engineers at cloud hosting companies… I feel bad for those people.
AFAIK, updated ucode can be loaded by the OS and by the BIOS/UEFI, and needs to be loaded at every boot. So bios and os updates can update the ucode.
I’m pretty sure windows includes it and loads it in without needing user interaction, and Linux definitely does if you have the ucode package, see here for arch linux, although it can also be built into the kernel.
Some of these mitigations can be disabled by the OS, but I have not looked into it very much.
Fortunately my BIOS allows me to disable not just hyperthreading, but individual cores too. I’ll disable everything but the first core, problem solved.