The "special register buffer data sampling" hardware vulnerability

Posted Jun 9, 2020 20:37 UTC (Tue) by cesarb (subscriber, #6266)
Parent article: The "special register buffer data sampling" hardware vulnerability

> 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>