Live data from Hacker News

AMD: Microcode Signature Verification Vulnerability

github.com

31–40 of 107 posts

Re: AMD: Microcode Signature Verification Vulnerability

#32

I don't know how exploitable this really is, as a lot of Linux systems load microcode at boot time... once it's been loaded, I don't think it's possible to load another one (outside of rebooting).

It is possible, but it's generally not a good idea.

https://wiki.archlinux.org/title/Microcode#Late_loading

https://docs.kernel.org/arch/x86/microcode.html#late-loading

although quotes from this article claim that it's fine specifically on AMD systems:

https://www.phoronix.com/news/AMD-Late-Loading-Microcode

Re: AMD: Microcode Signature Verification Vulnerability

#33

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 using strcmp and not memcmp on their hash comparisons in the Wii, so you only had to collide the function to the first \0).

Re: AMD: Microcode Signature Verification Vulnerability

#34
post #11

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.

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

Re: AMD: Microcode Signature Verification Vulnerability

#35

I don't know how exploitable this really is, as a lot of Linux systems load microcode at boot time... once it's been loaded, I don't think it's possible to load another one (outside of rebooting).

It is possible, but it's generally not a good idea. https://wiki.archlinux.org/title/Microcode#Late_loading https://docs.kernel.org/arch/x86/microcode.html#late-loading although quotes from this article claim that it's fine specifically on AMD systems: https://www.phoronix.com/news/AMD-Late-Loading-Microcode

To my understanding, part of the reason that was a problem was that Intel wanted to killswitch feature bits like SGX, but since Linux saves the feature bit state when it inits the CPUs, and then other things might change codepaths based on that, if you then killswitch it later, boom might go the dynamite.

(I believe this example would also still break on AMD-based systems, AMD just hasn't killswitched a CPUID feature flag yet AFAIR...)

Re: AMD: Microcode Signature Verification Vulnerability

#37
post #15

> 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 :)

Did you roll your own die or just trust that Randall's original die roll was sufficiently random?

Re: AMD: Microcode Signature Verification Vulnerability

#38
post #11

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.

Try to install your own patch for RDRAND and check that it is returning 4? Of course, getting 4 multiple times doesn't mean you have succeeded [0]. [0] https://duckduckgo.com/?q=dilbert+random+generator+nine+nine... (couldn't find a good link to the comic)

The exploit doesn't work in a VM.

Re: AMD: Microcode Signature Verification Vulnerability

#39
post #34
post #11

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.

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

Post reply on HN