The VUSec security researchers are at it again... The embargo is now lifted on another set of of security vulnerabilities affecting Intel processors as well as Arm core designs. This new vulnerability is dubbed Training Solo .

Security researchers discovered that domain isolation used for commonly mitigating Spectre Variant Two vulnerabilities have multiple shortcomings across different CPU architectures. Making matters worse, Training Solo exposes three separate variants with multiple mitigations needed.

The ITS variant of Training Solo requires an Intel CPU microcode update as well as software mitigations to the Linux kernel and KVM. There's also a Training Solo variant affecting Intel Lion Cove cores requiring a separate mitigation approach. Lastly, the third variant also requires an Intel microcode update as well as Intel and Arm software patches to the Linux kernel.

The VUSec security paper going live today explains: " In this paper, we challenge this assumption and show that even perfect domain isolation is insufficient to deter practical attacks. To this end, we systematically analyze self-training Spectre-v2 attacks, where both training and speculative control-flow hijacking occur in the same (victim) domain. While self-training attacks are believed to be limited to the in-domain scenario—where attackers can run arbitrary code and inject their own disclosure gadgets in a (default-off) sandbox such as eBPF—our analysis shows cross-domain variants are possible in practice. Specifically, we describe three new classes of attacks against the Linux kernel and present two end-to-end exploits that leak kernel memory on recent Intel CPUs at up to 17 KB/sec. During our investigation, we also stumbled upon two Intel issues which completely break (user, guest, and hypervisor) isolation and re-enable classic Spectre-v2 attacks. "

I was only notified a short time in advance of today's embargo lift on Training Solo, so I am still digging through the details myself. The Training Solo website for this vulnerability should be live now at [1]VUSec.net . As Linux kernel patches and new Intel CPU microcode becomes available, I will be conducting some benchmarks on them to measure any new associated overhead to these additional security mitigations.

Update: The [2]Indirect Target Selection mitigation (ITS) has been merged to Linux Git. Intel's Dave Hansen explains there:

I'd describe this one as a good old CPU bug where the behavior is _obviously_ wrong, but since it just results in bad predictions it wasn't wrong enough to notice. Well, the researchers noticed and also realized that thus bug undermined a bunch of existing indirect branch mitigations.

Thus the unusually wide impact on this one. Details:

ITS is a bug in some Intel CPUs that affects indirect branches including RETs in the first half of a cacheline. Due to ITS such branches may get wrongly predicted to a target of (direct or indirect) branch that is located in the second half of a cacheline. Researchers at VUSec found this behavior and reported to Intel.

Affected processors:

- Cascade Lake, Cooper Lake, Whiskey Lake V, Coffee Lake R, Comet

Lake, Ice Lake, Tiger Lake and Rocket Lake.

Plus the [3]Intra-mode Branch History Injection mitigation has also been merged to Linux Git:

Mitigate Intra-mode Branch History Injection via classic BFP programs

This adds the branch history clearing mitigation to cBPF programs for x86. Intra-mode BHI attacks via cBPF a.k.a IBTI-History was reported by researchers at VUSec.

For hardware that doesn't support BHI_DIS_S, the recommended mitigation is to run the short software sequence followed by the IBHF instruction after cBPF execution. On hardware that does support BHI_DIS_S, enable BHI_DIS_S and execute the IBHF after cBPF execution.

The Indirect Branch History Fence (IBHF) is a new instruction that prevents indirect branch target predictions after the barrier from using branch history from before the barrier while BHI_DIS_S is enabled. On older systems this will map to a NOP. It is recommended to add this fence at the end of the cBPF program to support VM migration. This instruction is required on newer parts with BHI_NO to fully mitigate against these attacks.

The current code disables the mitigation for anything running with the SYS_ADMIN capability bit set. The intention was not to waste time mitigating a process that has access to anything it wants anyway



[1] https://vusec.net/projects/training-solo

[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6f5bf947bab06f37ff931c359fd5770c4d9cbf87

[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=caf12fa9c066bb81e6a2f05dc441a89a1160c0fe