LWN: Comments on "The "special register buffer data sampling" hardware vulnerability"

The "special register buffer data sampling" hardware vulnerability

intgr — Mon, 22 Jun 2020 12:59:53 +0000

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

The "special register buffer data sampling" hardware vulnerability

clopez — Thu, 11 Jun 2020 01:08:10 +0000

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

pbonzini — Wed, 10 Jun 2020 20:32:44 +0000

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

mjg59 — Wed, 10 Jun 2020 20:12:44 +0000

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

pbonzini — Wed, 10 Jun 2020 20:10:26 +0000

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

pbonzini — Wed, 10 Jun 2020 20:03:21 +0000

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

mjg59 — Wed, 10 Jun 2020 19:57:58 +0000

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

The "special register buffer data sampling" hardware vulnerability

Cyberax — Wed, 10 Jun 2020 19:48:32 +0000

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

The "special register buffer data sampling" hardware vulnerability

mjg59 — Wed, 10 Jun 2020 19:39:26 +0000

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

pbonzini — Wed, 10 Jun 2020 18:49:12 +0000

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

zdzichu — Wed, 10 Jun 2020 15:49:40 +0000

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

jcm — Wed, 10 Jun 2020 15:33:48 +0000

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

Paf — Wed, 10 Jun 2020 14:51:30 +0000

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

nivedita76 — Wed, 10 Jun 2020 02:11:14 +0000

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

geofft — Wed, 10 Jun 2020 02:06:31 +0000

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

nivedita76 — Wed, 10 Jun 2020 01:50:26 +0000

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

Paf — Wed, 10 Jun 2020 01:15:43 +0000

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

cesarb — Tue, 09 Jun 2020 20:37:05 +0000

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