6 ms·

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

by wrs 2y ago

bestouff 2y ago
Yes ! I wonder what's the Windows implementation of the equivalent API.
- cluckindan 2y ago
  Run the patch and find out.
- loeg 2y ago
  > Windows 10 has many entropy sources; these work together to ensure that the OS has good entropy. Different entropy sources guarantee good entropy in different situations; by using them all the best coverage is attained. > Interrupt Timings > The primary entropy source in Windows 10 is the interrupt timings. On each interrupt to a CPU the interrupt hander gets the Time Stamp Count (TSC) from the CPU. This is typically a counter that runs on the CPU clock frequency; on X86 and X64 CPUs this is done using the RDTSC instruction. > ... > The Intel RDRAND instruction is an on-demand high quality source of random data. > If the RDRAND instruction is present, Winload gathers 256 bits of entropy from the RDRAND instruction. Similarly, our kernel-mode code creates a high-pull source that provides 512 bits of entropy from the RDRAND instruction for each reseed. (As a high source, the first 256 bits are always put in pool 0; providing 512 bits ensures that the other pools also get entropy from this source.) > Due to some unfortunate design decisions in the internal RDRAND logic, the RDRAND instruction only provides random numbers with a 128-bit security level. The Win10 code tries to work around this limitation by gathering a large amount of output from RDRAND which should trigger a reseed of the RDRAND-internal PRNG to get more entropy. Whilst this solves the problem in most cases, it is possible for another thread to gather similar outputs form RDRAND which means that a 256-bit security level cannot be guaranteed. > Based on our feedback about this problem, Intel implemented the RDSEED instruction that gives direct access to the internal entropy source. When the RDSEED instruction is present, it is used in preference to RDRAND instruction which avoids the problem and provides the full desired guarantees. For each reseed, we gather 128 output bytes from RDSEED, hash them with SHA-512 to produce 64 output bytes. As explained before, 32 of these go into pool 0 and the others into the ‘next’ pool for this entropy source. https://aka.ms/win10rng https://aka.ms/win10rng
rincebrain 2y ago
"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 hands...
- Tuna-Fish 2y ago
  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.
  - rincebrain 2y ago
    Sure, but as stated, if you don't trust the CPU at all, rdrand becomes the least of your concerns.
    - Tuna-Fish 2y ago
      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 priorities, but there is some cause to at least use it defensively, for example using it to pre-fill buffers with random values in a different context, so that subversion would in the very least require memory references, instead of running RDRAND in the context of your RNG.
      - Muromec 2y ago
        > 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?
c2xlZXB5Cg1 2y ago
Life imitates art: https://imgs.xkcd.com/comics/random_number.png https://imgs.xkcd.com/comics/random_number.png
- saagarjha 2y ago
  I assume the Google engineers have a sense of humor
- eptcyka 2y ago
  That's a reference to the PS3's RNG.
  - Karliss 2y ago
    I always thought the same when seeing that XKCD comic, but turns out it was the opposite. PS3 hack (2010) came 3 years after the XKCD comic(2007), they even used it as one of slides during 27C3 presentation. https://media.ccc.de/v/27c3-4087-en-console_hacking_2010#t=2332 https://media.ccc.de/v/27c3-4087-en-console_hacking_2010#t=2...
    - eptcyka 2y ago
      Oh my.
  - nicman23 2y ago
    oh fuck i had forget that blast of a presentation
- Lammy 2y ago
  I realize the OP is explicitly (w/r/t 4) a reference to XKCD, but See Also: Dilbert 2001-10-25 :) https://web.archive.org/web/20011027002011/http://www.dilbert.com/comics/dilbert/archive/images/dilbert2001182781025.gif https://web.archive.org/web/20011027002011/http://www.dilber... https://dilbert-viewer.herokuapp.com/2001-10-25 https://dilbert-viewer.herokuapp.com/2001-10-25
monocasa 2y ago
I wouldn't focus so much on the rdrand part. That's more a proof that they have crafted a custom microcode than trying to say that rdrand is broken.
- wrs 2y ago
  I think the argument for entropy mixing was that RDRAND could be broken, not that it was broken. On these processors, apparently yes it could.
  - monocasa 2y ago
    Rdrand was known to be previously broken. https://www.reddit.com/r/archlinux/comments/1d9aazw/rdrand_not_working_on_amd_cpu/ https://www.reddit.com/r/archlinux/comments/1d9aazw/rdrand_n...
Aardwolf 2y ago
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

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

by wrs 2y ago

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

bestouff 2y ago

Yes ! I wonder what's the Windows implementation of the equivalent API.

cluckindan 2y ago
Run the patch and find out.
loeg 2y ago
> Windows 10 has many entropy sources; these work together to ensure that the OS has good entropy. Different entropy sources guarantee good entropy in different situations; by using them all the best coverage is attained. > Interrupt Timings > The primary entropy source in Windows 10 is the interrupt timings. On each interrupt to a CPU the interrupt hander gets the Time Stamp Count (TSC) from the CPU. This is typically a counter that runs on the CPU clock frequency; on X86 and X64 CPUs this is done using the RDTSC instruction. > ... > The Intel RDRAND instruction is an on-demand high quality source of random data. > If the RDRAND instruction is present, Winload gathers 256 bits of entropy from the RDRAND instruction. Similarly, our kernel-mode code creates a high-pull source that provides 512 bits of entropy from the RDRAND instruction for each reseed. (As a high source, the first 256 bits are always put in pool 0; providing 512 bits ensures that the other pools also get entropy from this source.) > Due to some unfortunate design decisions in the internal RDRAND logic, the RDRAND instruction only provides random numbers with a 128-bit security level. The Win10 code tries to work around this limitation by gathering a large amount of output from RDRAND which should trigger a reseed of the RDRAND-internal PRNG to get more entropy. Whilst this solves the problem in most cases, it is possible for another thread to gather similar outputs form RDRAND which means that a 256-bit security level cannot be guaranteed. > Based on our feedback about this problem, Intel implemented the RDSEED instruction that gives direct access to the internal entropy source. When the RDSEED instruction is present, it is used in preference to RDRAND instruction which avoids the problem and provides the full desired guarantees. For each reseed, we gather 128 output bytes from RDSEED, hash them with SHA-512 to produce 64 output bytes. As explained before, 32 of these go into pool 0 and the others into the ‘next’ pool for this entropy source. https://aka.ms/win10rng https://aka.ms/win10rng

rincebrain 2y ago

"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 hands...

Tuna-Fish 2y ago
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.
- rincebrain 2y ago
  Sure, but as stated, if you don't trust the CPU at all, rdrand becomes the least of your concerns.
  - Tuna-Fish 2y ago
    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 priorities, but there is some cause to at least use it defensively, for example using it to pre-fill buffers with random values in a different context, so that subversion would in the very least require memory references, instead of running RDRAND in the context of your RNG.
    - Muromec 2y ago
      > 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?

c2xlZXB5Cg1 2y ago

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

saagarjha 2y ago
I assume the Google engineers have a sense of humor
eptcyka 2y ago
That's a reference to the PS3's RNG.
- Karliss 2y ago
  I always thought the same when seeing that XKCD comic, but turns out it was the opposite. PS3 hack (2010) came 3 years after the XKCD comic(2007), they even used it as one of slides during 27C3 presentation. https://media.ccc.de/v/27c3-4087-en-console_hacking_2010#t=2332 https://media.ccc.de/v/27c3-4087-en-console_hacking_2010#t=2...
  - eptcyka 2y ago
    Oh my.
- nicman23 2y ago
  oh fuck i had forget that blast of a presentation
Lammy 2y ago
I realize the OP is explicitly (w/r/t 4) a reference to XKCD, but See Also: Dilbert 2001-10-25 :) https://web.archive.org/web/20011027002011/http://www.dilbert.com/comics/dilbert/archive/images/dilbert2001182781025.gif https://web.archive.org/web/20011027002011/http://www.dilber... https://dilbert-viewer.herokuapp.com/2001-10-25 https://dilbert-viewer.herokuapp.com/2001-10-25

monocasa 2y ago

I wouldn't focus so much on the rdrand part. That's more a proof that they have crafted a custom microcode than trying to say that rdrand is broken.

wrs 2y ago
I think the argument for entropy mixing was that RDRAND could be broken, not that it was broken. On these processors, apparently yes it could.
- monocasa 2y ago
  Rdrand was known to be previously broken. https://www.reddit.com/r/archlinux/comments/1d9aazw/rdrand_not_working_on_amd_cpu/ https://www.reddit.com/r/archlinux/comments/1d9aazw/rdrand_n...

Aardwolf 2y ago

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