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

71–80 of 107 posts

Re: AMD: Microcode Signature Verification Vulnerability

#71

Post by jstasiak »

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.

An article mentioning this kind of attack: https://blog.cr.yp.to/20140205-entropy.html

Re: AMD: Microcode Signature Verification Vulnerability

#72

Post by usrusr »

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?

Had the same thought. But then on the other hand, when nobody is looking at the timing, nobody will see anything. And those who do see a timing artifact, will they really dig deeper or will they just shrug off another oddity? I would not like to bet on another Clifford Stoll in this day and age.

Re: AMD: Microcode Signature Verification Vulnerability

#73

Post by _rdvw »

Reminder that AMD has stopped providing microcode updates for consumer platforms via linux-firmware.

index of linux-firmware, 41 cpus supported: https://github.com/divestedcg/real-ucode/blob/master/index-a...

index of my real-ucode project, 106 cpus supported: https://github.com/divestedcg/real-ucode/blob/master/index-a...

sadly, unless you have this recent agesa update you can no longer load recent microcodes due to this fix

which very well means quite a substantial amount of models whose vendors don't provide a bios update for this (since it goes back to zen1) will not be able to load any future fixes via microcode

Re: AMD: Microcode Signature Verification Vulnerability

#74

Post by monocasa »

wrs wrote: post #65
monocasa wrote: post #50

Earlier quoted context omitted.

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.

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.

Rdrand was known to be previously broken.

https://www.reddit.com/r/archlinux/comments/1d9aazw/rdrand_n...

Re: AMD: Microcode Signature Verification Vulnerability

#75

Post by ngneer »

mindslight wrote: post #69
xmodem wrote: post #56

Security implications aside, the ability to load custom microcode onto these chips could have fascinating implications for reverse engineering and understanding them better.

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 am all for Right to Repair, and am upset with the "evil overlords" as much as the next guy. But, to present the treacherous computing argument all on its own, is, well, incomplete. I am a huge fan of Ross Anderson, RIP. However, the reality is that while DRTM was originally envisioned primarily for DRM applications, it is nowadays leveraged to protect PCs against bootkits and the like. YOU may like to own your computer through and through, down to the microcode, but, for most people, their computer is viewed as a product, that they trust vendors to secure for them. If ultimate control is so important to you, can you not buy any machine you like, including one based on a RISC-V open-source processor?

https://community.amd.com/t5/business/amd-and-microsoft-secu...

Re: AMD: Microcode Signature Verification Vulnerability

#76

Post by anon2025b »

bpye wrote: post #39
wmf wrote: post #34

Earlier quoted context omitted.

In theory the PSP should probably attest the microcode but I don't know if that exists.

SEV-SNP VMs can obtain an attestation report [0]. [0] - https://www.amd.com/content/dam/amd/en/documents/epyc-techni...

What does it actually attest though?

The running microcode's revision ID?

Or the running microcode's ROM version plus loaded patch lines plus active match registers plus whatever settings were adjusted in config registers during the act of loading?

That is, attest the actual and complete config that is running, or some pointless subset that instills a false sense of security?

It would be good for AMD (and Intel etc.) to provide better details here.

Re: AMD: Microcode Signature Verification Vulnerability

#77

Post by pabs3 »

xmodem wrote: post #56

Security implications aside, the ability to load custom microcode onto these chips could have fascinating implications for reverse engineering and understanding them better.

I wonder how much of the built-in microcode you could replace with Free-as-in-Freedom equivalents, I expect not all of it due to available SRAM?

Re: AMD: Microcode Signature Verification Vulnerability

#78

Post by mindslight »

ngneer wrote: post #75
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 am all for Right to Repair, and am upset with the "evil overlords" as much as the next guy. But, to present the treacherous computing argument all on its own, is, well, incomplete. I am a huge fan of Ross Anderson, RIP. However, the reality is that while DRTM was originally envisioned primarily for DRM applications, it is nowadays leveraged to protect PCs against bootkits and the like. YOU may like to own your comp…

> If ultimate control is so important to you, can you not buy any machine you like, including one based on a RISC-V open-source processor?

This argument (or the individualist approach in general) no longer works in the context of remote attestation ("Dynamic Root of Trust Measurement"). As soon as the "average person" has a computer that can be counted on to betray what software they're running, remote parties will start turning the screws of coercion and making everyone use such a machine.

Re: AMD: Microcode Signature Verification Vulnerability

#79

Post by _rdvw »

rincebrain wrote: post #33
dooglius wrote: post #29

Doesn't this give enough detail for someone to replicate easily? I'd think it would not be too hard to look at the signature and find the insecure function used.

There's been a bunch of scattered public research on microcode payload signatures over the years. I would speculate that the problem is less that the hash function is weak inherently (otherwise we'd have a really complicated horizon of needing to chain microcode updates since we'd eventually want to e.g. go from MD5 to SHA1 or something), and more that the implementation has a flaw (similar to things like Nintendo us…

recent microcode appears to be rejected by older agesa in my testing, so it is very possible it is more than an implementation issue

under agesa 1.2.0.2b

> microcode: CPU1: update failed for patch_level=0x0a60120c

under agesa 1.2.0.3a PatchA (which asus leaked that it fixes this issue)

> microcode: Updated early from: 0x0a60120c

Re: AMD: Microcode Signature Verification Vulnerability

#80

Post by basementcat »

AnotherGoodName wrote: post #57
xmodem wrote: post #56

Security implications aside, the ability to load custom microcode onto these chips could have fascinating implications for reverse engineering and understanding them better.

Also I’m curious if there’s opportunity for an all out perf variant from home brewers. Eg. Throw away all spectre mitigations, find all the hacks to get each instructions timing down, etc.

While you’re at it, allow for a few more ulp (units of least place) error for floating point ops.
Post reply on HN