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

21–30 of 107 posts

Re: AMD: Microcode Signature Verification Vulnerability

#21

Post by Tuna-Fish »

rincebrain wrote: post #12
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?

"in theory" Linux, at least, was supposed to use rdrand's output as _one_ source of entropy, not _the only_ source. No idea what Windows et al do for this, or if that's still true, but I believe the above description was how the argument was originally ended. Also, tbh, if you can patch arbitrary instruction behavior, just replacing rdrand seems like far too ham fisted a tool with the level of versatility in your han…

Linux's rdrand use is proof against it returning bad output, but is not proof against malicious microcode. Reason for this is that the malicious microcode can examine register contents and alter the value it's returning so that mixing it into the previous source of randomness produces the desired evil value.

Re: AMD: Microcode Signature Verification Vulnerability

#22

Post by wahern »

rincebrain wrote: post #12
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?

"in theory" Linux, at least, was supposed to use rdrand's output as _one_ source of entropy, not _the only_ source. No idea what Windows et al do for this, or if that's still true, but I believe the above description was how the argument was originally ended. Also, tbh, if you can patch arbitrary instruction behavior, just replacing rdrand seems like far too ham fisted a tool with the level of versatility in your han…

For organizations like the NSA, a simple hack like this is the opposite of ham-fisted, though presumably they'd try to ensure the output would pass common statistical tests. The utility in quietly breaking cryptographic protocols is presumably a major reason why it was chosen for the proof-of-concept.

Re: AMD: Microcode Signature Verification Vulnerability

#23

Post by dooglius »

rincebrain wrote: post #12
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?

"in theory" Linux, at least, was supposed to use rdrand's output as _one_ source of entropy, not _the only_ source. No idea what Windows et al do for this, or if that's still true, but I believe the above description was how the argument was originally ended. Also, tbh, if you can patch arbitrary instruction behavior, just replacing rdrand seems like far too ham fisted a tool with the level of versatility in your han…

Intel's theory I believe was that it could become the only source. The argument in favor I think is the same one you are making now: anything that could hack the chip deeply enough to break rdrand is powerful enough to achieve the same goals in another way.

Re: AMD: Microcode Signature Verification Vulnerability

#24

Post by rincebrain »

Tuna-Fish wrote: post #21
rincebrain wrote: post #12

Earlier quoted context omitted.

"in theory" Linux, at least, was supposed to use rdrand's output as _one_ source of entropy, not _the only_ source. No idea what Windows et al do for this, or if that's still true, but I believe the above description was how the argument was originally ended. Also, tbh, if you can patch arbitrary instruction behavior, just replacing rdrand seems like far too ham fisted a tool with the level of versatility in your han…

Linux's rdrand use is proof against it returning bad output, but is not proof against malicious microcode. Reason for this is that the malicious microcode can examine register contents and alter the value it's returning so that mixing it into the previous source of randomness produces the desired evil value.

Sure, but as stated, if you don't trust the CPU at all, rdrand becomes the least of your concerns.

Re: AMD: Microcode Signature Verification Vulnerability

#25

Post by saagarjha »

c2xlZXB5Cg1 wrote: post #17
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?

Life imitates art: https://imgs.xkcd.com/comics/random_number.png

I assume the Google engineers have a sense of humor

Re: AMD: Microcode Signature Verification Vulnerability

#26

Post by rincebrain »

wahern wrote: post #22
rincebrain wrote: post #12

Earlier quoted context omitted.

"in theory" Linux, at least, was supposed to use rdrand's output as _one_ source of entropy, not _the only_ source. No idea what Windows et al do for this, or if that's still true, but I believe the above description was how the argument was originally ended. Also, tbh, if you can patch arbitrary instruction behavior, just replacing rdrand seems like far too ham fisted a tool with the level of versatility in your han…

For organizations like the NSA, a simple hack like this is the opposite of ham-fisted, though presumably they'd try to ensure the output would pass common statistical tests. The utility in quietly breaking cryptographic protocols is presumably a major reason why it was chosen for the proof-of-concept.

Sure, but that was my point, was that just overriding rdrand would be much more ham-fisted than any practical attack I would expect someone to weaponize this into outside of a PoC.

Re: AMD: Microcode Signature Verification Vulnerability

#27

Post by saagarjha »

nspaced wrote: post #15
unsnap_biceps wrote: post #8

> A test payload for Milan and Genoa CPUs that makes the RDRAND instruction return 4 I would be tickled pink if the 4 was in reference to https://xkcd.com/221/

Hi, I'm one of the authors and yes it was :)

We thank you for your service

Re: AMD: Microcode Signature Verification Vulnerability

#30

Post by rincebrain »

dooglius wrote: post #23
rincebrain wrote: post #12

Earlier quoted context omitted.

"in theory" Linux, at least, was supposed to use rdrand's output as _one_ source of entropy, not _the only_ source. No idea what Windows et al do for this, or if that's still true, but I believe the above description was how the argument was originally ended. Also, tbh, if you can patch arbitrary instruction behavior, just replacing rdrand seems like far too ham fisted a tool with the level of versatility in your han…

Intel's theory I believe was that it could become the only source. The argument in favor I think is the same one you are making now: anything that could hack the chip deeply enough to break rdrand is powerful enough to achieve the same goals in another way.

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...
Post reply on HN