The "special register buffer data sampling" hardware vulnerability

[Posted June 9, 2020 by corbet]

We have not had a new CPU vulnerability for a little while — a situation that was clearly too good to last. The mainline kernel has just merged mitigations for the "special register buffer data sampling" vulnerability which, in short, allows an attacker to spy on the random numbers obtained by others. In particular, the results of the RDRAND instruction can be obtained via a speculative attack.

The mitigation involves more flushing and the serialization of RDRAND. That means a RDRAND instruction will take longer to run, but it also means that RDRAND requires locking across the system, which will slow things considerably if it is executed frequently. There are ways to turn the mitigations off, of course. See this new kernel document for more information.

These fixes are currently queued to be part of the 5.7.2, 5.6.18, 5.4.46, 4.19.128, 4.14.184 4.9.227, 4.4.227, and 3.16.85 stable updates.

The "special register buffer data sampling" hardware vulnerability

Posted Jun 9, 2020 20:37 UTC (Tue) by cesarb (subscriber, #6266) [Link] (12 responses)

> Executing RDRAND, RDSEED or EGETKEY will delay memory accesses from other logical processors that miss their core caches, with an impact similar to legacy locked cache-line-split accesses.

Does this mean that all the work on split lock detection (https://lwn.net/Articles/790464/ and https://lwn.net/Articles/806466/) was for nothing, since even with split lock detection enabled, unprivileged user space can use RDRAND for the same effect?

The "special register buffer data sampling" hardware vulnerability

Posted Jun 10, 2020 1:15 UTC (Wed) by Paf (subscriber, #91811) [Link] (3 responses)

No, I don’t think so - what’s being described here is the kernel usage of the instruction being protected. It’s just a CPU instruction, not a syscall. The kernel cannot and does not take responsibility for protecting user space users of RDRAND. It’s just adding protections to its own usages of the instruction.

The "special register buffer data sampling" hardware vulnerability

Posted Jun 10, 2020 1:50 UTC (Wed) by nivedita76 (subscriber, #121790) [Link] (2 responses)

Nope. The mitigation is not by the kernel, it is in microcode. The kernel merely sets a bit in an MSR to tell the microcode to mitigate it.

So with mitigation enabled, userspace code can indeed can use RDRAND to lock the memory bus.

The "special register buffer data sampling" hardware vulnerability

Posted Jun 10, 2020 2:11 UTC (Wed) by nivedita76 (subscriber, #121790) [Link] (1 responses)

However, this shouldn't have any overlap with split-lock detection. That is a new feature on yet-to-be-released processors, which presumably will not be vulnerable to SRBDS.

The "special register buffer data sampling" hardware vulnerability

Posted Jun 10, 2020 14:51 UTC (Wed) by Paf (subscriber, #91811) [Link]

Ahh, I misunderstood. The referenced serialization and clearing etc are in hardware, and the kernel patches exist solely to control (on, off, etc) the new microcode features. Ok, thanks!

The "special register buffer data sampling" hardware vulnerability

Posted Jun 10, 2020 18:49 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (7 responses)

Split lock detection blocks the whole bus, not just the package. Also you can hide RDRAND and RDSEED from VMs and they will not be able to block the whole package.

The "special register buffer data sampling" hardware vulnerability

Posted Jun 10, 2020 19:39 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (6 responses)

Does libvirt have support for this? Presumably the idea is to clear the rdrand/rdseed cpuid capabilities from the guest, and then set the "rdrand exiting" flag so if it uses the instructions anyway it'll trap and you can shut it down?

The "special register buffer data sampling" hardware vulnerability

Posted Jun 10, 2020 19:48 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

The problem is that clients can run RDRAND even if there are no capability bits set.

The "special register buffer data sampling" hardware vulnerability

Posted Jun 10, 2020 19:57 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (2 responses)

There's a flag you can set to trigger a vmexit on rdrand/rdseed

The "special register buffer data sampling" hardware vulnerability

Posted Jun 10, 2020 20:12 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (1 responses)

I spent a while wondering *why* there's a flag to do this on these specific instructions and the best answer I found was to allow the host to provide the same random numbers to multiple guests in order to allow "best out of three" type validation without having to rewrite code that uses rdrand. Which doesn't seem like a great answer tbf (why not just use a paravirt rng?), but it worked out fortunately for this case.

The "special register buffer data sampling" hardware vulnerability

Posted Jun 10, 2020 20:32 UTC (Wed) by pbonzini (subscriber, #60935) [Link]

Yes, making the execution deterministic is a good reason to let the hypervisor block the TRNG.

In this case it turned out to be a happy accident that the code to mitigate SRBDS from KVM was already implemented, which certainly was a relieve for me compared to ITLB multihit last fall...

The "special register buffer data sampling" hardware vulnerability

Posted Jun 10, 2020 20:03 UTC (Wed) by pbonzini (subscriber, #60935) [Link]

KVM checks whether the features have been hidden, and enables the bits that mjg59 mentioned. It the injects an undefined opcode exception when it gets the vmexit.

The "special register buffer data sampling" hardware vulnerability

Posted Jun 10, 2020 20:10 UTC (Wed) by pbonzini (subscriber, #60935) [Link]

Yes, exactly. You have to add the <feature> XML element inside <cpu>; for example:

<cpu mode='host-model'>
<feature policy='disable' name='rdrand'/>
<feature policy='disable' name='rdseed'/>
</cpu>

The "special register buffer data sampling" hardware vulnerability

Posted Jun 10, 2020 2:06 UTC (Wed) by geofft (subscriber, #59789) [Link] (3 responses)

Here's a writeup of the attack with some more details: https://www.vusec.net/projects/crosstalk/

The new notable thing about the attack is that the "special registers" are shared across CPU cores, so you can attack one CPU core from another (e.g. an SGX enclave on another core, another customer on the same public cloud hypervisor, etc). Previous attacks required the exploit code to run on the same core as the victim.

The "special register buffer data sampling" hardware vulnerability

Posted Jun 10, 2020 15:33 UTC (Wed) by jcm (subscriber, #18262) [Link] (2 responses)

Any time you have uncore shared data readable by multiple cores, you want to be very careful what's in there...

The "special register buffer data sampling" hardware vulnerability

Posted Jun 10, 2020 15:49 UTC (Wed) by zdzichu (subscriber, #17118) [Link] (1 responses)

We have Zero Trust network. Is this the time for Zero Trust CPUs? Where each core is potentially malicous towards other cores?

The "special register buffer data sampling" hardware vulnerability

Posted Jun 11, 2020 1:08 UTC (Thu) by clopez (guest, #66009) [Link]

People that dont trust each other was sharing the same network... and now they share the same CPU (VMs in the "cloud").. so yes

The "special register buffer data sampling" hardware vulnerability

Posted Jun 22, 2020 12:59 UTC (Mon) by intgr (subscriber, #39733) [Link]

Does this mitigation have any effect on AMD CPUs that also support RDRAND/RDSEED?