Researchers found a way to bypass the latest Spectre mitigations and exploit AMD and Intel processors to leak secrets like passwords and encryption keys.
would nosmt=forceprotect from this bypass?
I think speculative execution is different from multithreading.
They also contacted the Linux kernel about it. Reportedly, a patch has landed in the kernel now.
How do I find out which kernels that patch is in so I can make sure I’m safe?
If I am understanding how tags work correctly (which I may not be), based on the GitHub mirror, the patch is not in any stable release yet. It is part of the 7.2-rc7 tag (rc likely meaning “release candidate”) which was only made 2 days ago. Based on that, I’d expect the patch to be in the stable release of 7.2.
This is probably going to keep happening forever. It’s just patching holes in a flawed concept. However, the speed increase is likely such that this kind of thing will be tolerated—right up until enough money has been lost because of the vulnerabilities that speculative execution imparts.
It’s definitely going to need a fundamental shift in how operating systems handle security, I don’t think the monolithic kernel idea is going to cut it anymore in 2026 and moving forward.
Would microkernels help with this kind of bug? How?
Yes but many speculative execution bugs are only exploitable with hyperthreading enabled, and in fact disabling SMT can be required for full protection
on CPUs which are affected by MFBDS or MLPDS it is necessary to disable SMT for full protection
The same as tsx_async_abort=full, with SMT disabled on vulnerable CPUs that have TSX enabled. This is the complete mitigation.
To prevent the SMT issues of L1TF it might be necessary to disable SMT completely
However, I don’t believe that is the case for Spectre, and disabling SMT at most only provides partial mitigation for some ways of exploiting Spectre.
On systems with simultaneous multi-threading (SMT), attacks are possible from the sibling thread, as level 1 cache and branch target buffer (BTB) may be shared between hardware threads in a CPU core. A malicious program running on the sibling thread may influence its peer’s BTB to steer its indirect branch speculations to gadget code, and measure the speculative execution’s side effects left in level 1 cache to infer the victim’s data.
A malicious user process can try to attack another user process, either via a context switch on the same hardware thread, or from the sibling hyperthread sharing a physical processor core on simultaneous multi-threading (SMT) system.
If SMT is used, Spectre variant 2 attacks from an untrusted guest in the sibling hyperthread can be mitigated by the administrator, by turning off the unsafe guest’s indirect branch speculation via
prctl(). A guest can also protect itself by turning on microcode based mitigations (such as IBPB or STIBP on x86) within the guest.
These scenarios are not the only shapes a Spectre attack might take. Disabling SMT can help but not fully mitigate the vulnerability.
No.