61–70 of 107 posts
Earlier quoted context omitted.
Life imitates art: https://imgs.xkcd.com/comics/random_number.png
That's a reference to the PS3's RNG.
As an end user, I wonder how my cloud provider can prove to me that they installed AMD's fix and are not simply running a malicious version of the microcode on their CPU that claims to have the fix.
It's in the CVE: "AMD SEV-SNP users can verify the fix by confirming TCB values for SNP in their attestation reports." You can read about how this works here: https://www.amd.com/content/dam/amd/en/documents/epyc-techni... If you aren't using SEV-SNP / attested compute, you have bigger fish to fry anyway since you have no actual trust in your hypervisor.
I personally evaluated this technology a few years ago, and even just moving a small part of our team's workload to SEV-SNP faced so much resistance from the VP level. I'm not sure if that's more of a problem with bureaucracy at my old employer or a general problem.
Earlier quoted context omitted.
It's in the CVE: "AMD SEV-SNP users can verify the fix by confirming TCB values for SNP in their attestation reports." You can read about how this works here: https://www.amd.com/content/dam/amd/en/documents/epyc-techni... If you aren't using SEV-SNP / attested compute, you have bigger fish to fry anyway since you have no actual trust in your hypervisor.
While I agree with you, from experience most people and most workloads definitely aren't using SEV-SNP. The hypervisor and the cloud provider are always assumed to be honest. I personally evaluated this technology a few years ago, and even just moving a small part of our team's workload to SEV-SNP faced so much resistance from the VP level. I'm not sure if that's more of a problem with bureaucracy at my old employer…
"A test payload for Milan and Genoa CPUs that makes the RDRAND instruction return 4"... Turns out kernel RNG belt-and-suspenders was justified?
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.
Earlier quoted context omitted.
Sure, but as stated, if you don't trust the CPU at all, rdrand becomes the least of your concerns.
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…
Should you not see it from timing alone being wrong?
Earlier quoted context omitted.
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.
Security implications aside, the ability to load custom microcode onto these chips could have fascinating implications for reverse engineering and understanding them better.
> 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 people who write this upside-down corpo newspeak are so coked up on the authoritarian paradigm that they've lost touch with the reality, or if they're just paid well enough by the corpos to not care about making society worse, or what. But I'll translate:
This "vulnerability" might be used by the owner of a computer to inspect what their computer is actually doing or to defend themselves against coercion aiming to control the software they're running.
"A test payload for Milan and Genoa CPUs that makes the RDRAND instruction return 4"... Turns out kernel RNG belt-and-suspenders was justified?
Yes ! I wonder what's the Windows implementation of the equivalent API.
> 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.