Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AMD: Microcode Signature Verification Vulnerability

github.com

Post reply on HN
Print view View original

101–107 of 107 posts

Re: AMD: Microcode Signature Verification Vulnerability

#101

Post by Aardwolf »

wrs wrote: post #4

"A test payload for Milan and Genoa CPUs that makes the RDRAND instruction return 4"... Turns out kernel RNG belt-and-suspenders was justified?

Can a CPU implement RDRAND however it wants, or are there specifications that constrain it in some way?

E.g. if a CPU were to put a microscopic lavalamp and camera inside it and use a hash code of pictures taken from this lavalamp as the result of RDRAND: would that be compliant?

I know microscopic lavalamp in CPU is not physically feasible, what I'm asking is if RDRAND is broken by design, or proper physics based RNG's could be used to implement if a CPU maker wanted to

Re: AMD: Microcode Signature Verification Vulnerability

#102

Post by ChocolateGod »

account42 wrote: post #97

"This vulnerability allows an adversary with local administrator privileges (ring 0 from outside a VM) to load malicious microcode patches." "Vulnerability" These restrictions should never have been in place in the first place.

If the attacker has ring 0 outside a VM, don't they have full access to the memory and execution state anyway?

Re: AMD: Microcode Signature Verification Vulnerability

#103

Post by Tuna-Fish »

Muromec wrote: post #66
Tuna-Fish wrote: post #48

Earlier quoted context omitted.

The thing is, all the other ways you can compromise the kernel from microcode are at least theoretically detectable. A security researcher could study how the cpu operates and find the exploit. If RDRAND is surreptitiously replacing all your random numbers with AES of the current time, you cannot find that out from observing behavior. I agree that worrying about RDRAND shouldn't probably be on the top of anyone's pri…

> If RDRAND is surreptitiously replacing all your random numbers with AES of the current time, you cannot find that out from observing behavior. Should you not see it from timing alone being wrong?

RDRAND is very slow and you can fix up the timing with a slowdown loop in the microcode.

Re: AMD: Microcode Signature Verification Vulnerability

#104

Post by adrian_b »

ChocolateGod wrote: post #102
account42 wrote: post #97

"This vulnerability allows an adversary with local administrator privileges (ring 0 from outside a VM) to load malicious microcode patches." "Vulnerability" These restrictions should never have been in place in the first place.

If the attacker has ring 0 outside a VM, don't they have full access to the memory and execution state anyway?

On AMD server CPUs, the administrator of the cloud/datacenter is supposed to not have access to the encrypted memory used by customers' VMs.

This vulnerability breaks this assumption.

Re: AMD: Microcode Signature Verification Vulnerability

#105

Post by mindslight »

j16sdiz wrote: post #91
mindslight wrote: post #69

Earlier quoted context omitted.

Security implications? This is a win for distributed security - it's a "vulnerability" in the sense of the end of a movie where the evil overlord's plan falls apart. > This vulnerability could be used by an adversary to compromise confidential computing workloads protected by the newest version of AMD Secure Encrypted Virtualization, SEV-SNP or to compromise Dynamic Root of Trust Measurement. I don't know whether the…

I can't follow the logic. In the context of remote attestation, they can revoke the key and vulnerability like these won't help.

I was talking about the direct capabilities.

You're talking about the first order reaction.

The reaction to that reaction is that the noose of remote attestation develops slower. As things currently stand, they can't revoke the attestation keys of all the affected processors with websites (etc) just telling the large numbers of people with with those computers that they need to buy new ones. Rather the technological authoritarians have to continue waiting for a working scheme before they can push the expectation of remote attestation being something that is required.

Re: AMD: Microcode Signature Verification Vulnerability

#107

Post by rincebrain »

formerly_proven wrote: post #58
rincebrain wrote: post #30

Earlier quoted context omitted.

I'm sure Intel loved that idea, given that I don't think RDRAND showed up on AMD chips for 3 years after Intel launched support for it, and that would let them look much better on a number of benchmarks for that duration...

I think you misunderstand where in the pipeline RDRAND would sit. It's not a high-performance RNG, that instruction takes hundreds of cycles and generates a couple bytes of data. It's used to derive keys for the actual CSPRNG providing e.g. /dev/urandom (which is basically a stream cipher). Having or not having RDRAND would have no performance impact on the CSPRNG.

Sure, but as I recall, in those days, the system would happily block for a bit if you managed to drain the estimated entropy pool low enough by doing something like generating an openssh key on first boot, so having another source that the competition takes 3 years to implement could have provided noticable performance benefits for things people notice, like how slow first boot is, in the days before zx2c4 looked at Linux's /dev/random code and hit it with hammers.

(I'm not insisting on that workflow or example being an uptick, just that that's a concrete example of how having an additional source back then could have caused noticable performance differences. I'm aware you're not calling rdrand for your /dev/urandom or random accesses, now or then.)

Post reply on HN