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

91–100 of 107 posts

Re: AMD: Microcode Signature Verification Vulnerability

#91

Post by j16sdiz »

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 can't follow the logic.

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

Re: AMD: Microcode Signature Verification Vulnerability

#92

Post by basementcat »

basementcat wrote: post #80
AnotherGoodName wrote: post #57

Earlier quoted context omitted.

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.

Kidding aside, my understanding is this sort of thing cannot be microcode patched.

But I would be pleased to be proven wrong.

Re: AMD: Microcode Signature Verification Vulnerability

#93

Post by ec109685 »

thayne wrote: post #81

High seems a bit extreme to me. If you have something malicious running in ring 0, you are already in big trouble.

The idea of confidential compute / AMD Secure Encrypted Virtualization is that even with root outside the VM, you can't read the memory of the workloads running within a VM. Additionally, those inner workloads can attest that they are running in a secure environment.

Re: AMD: Microcode Signature Verification Vulnerability

#96

Post by Lockal »

basementcat wrote: post #92
basementcat wrote: post #80

Earlier quoted context omitted.

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

Kidding aside, my understanding is this sort of thing cannot be microcode patched. But I would be pleased to be proven wrong.

It can be patched, see example in "constant-time hardware division" section in https://misc0110.net/files/cpu_woot23.pdf (code: https://github.com/pietroborrello/CustomProcessingUnit/blob/...). You probably won't observe any improvement unless you know an algo massively better than reciprocals+newton.

Re: AMD: Microcode Signature Verification Vulnerability

#98

Post by p_l »

pabs3 wrote: post #77
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?

Unless you want to break the CPU, huge portions would have to be bit-to-bit equal, which makes the exercise have easy lower value (is it "free as in freedom" if it's effectively a bit wise copy?) while adding legal issues (it would not just be derivative work, it works be mostly an exact copy)

Re: AMD: Microcode Signature Verification Vulnerability

#99

Post by ZiiS »

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.

"This vulnerability allows a local administrator (ring 0 from outside a VM) to load clean microcode patches free of the vendor's malicious features."
Post reply on HN