12 ms·
AMD: Microcode Signature Verification Vulnerability
- 9cb14c1ec0 2y agoMove over Android ROM enthusiasts, real geeks run their own microcode.
- dmitrygr 2y ago> we will not be sharing full details at this time in order to give users time to re-establish trust on their confidential-compute workloads. What a load of shit! Confidence is earned, it does not grow back like a weed you stepped on!
- kmeisthax 2y agoThey promised additional details in March - a month away. If they don't release that information in March then you can sharpen your pitchforks.
- unsnap_biceps 2y agoI feel like this is a technical trust re-establishment, hence calling out specifically confidential-compute workloads
- Stevvo 2y agoThey only shared it now because Asus accidentally leaked it in release notes for a BIOS update Beta.
- ThatMedicIsASpy 2y agoWith ASUS leaking the fix in a beta bios one could go that route.
- dboreham 2y ago> CPU uses an insecure hash function in the signature validation Do we know what this "insecure hash function" is/was?
- 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 agoYes ! I wonder what's the Windows implementation of the equivalent API.
- cluckindan 2y agoRun 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
- unsnap_biceps 2y ago> 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/ https://xkcd.com/221/
- vardump 2y agoOf course it was.
- nspaced 2y agoHi, I'm one of the authors and yes it was :)
- saagarjha 2y agoWe thank you for your service
- rcthompson 2y agoDid you roll your own die or just trust that Randall's original die roll was sufficiently random?
- ikiris 2y agoIt’s a well recognized standard
- hedora 2y agoAs 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.
- kyrra 2y agoFor the large providers (Amazon, Google, Microsoft), they buy so many CPUs that they for issues like this, they tend to be given the fixes before they are released to the public. So I'd wager that those 3 already have patched their entire fleet.
- rincebrain 2y agoI don't think you can, necessarily, except by basically declaring bankruptcy on the old trust root on the systems and teaching everyone not to trust the old root. As long as the vulnerability doesn't let them actually extract the secrets necessary to simulate completely arbitrary operations including with any future keys, I _think_ you can trust the new attestation chain afterward? I've not been paid to work on this, though, and it would be pretty easy to have accidentally built it in a way where this is a world-ending event, and truly paranoid workloads in the future are going to insist on only using silicon that can't have ever been compromised by this either way.
- cluckindan 2y agohugs the Q6600 don’t you ever die on me, you precious space heater.
- bornfreddy 2y agoTry 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&t=fpas&iar=images&iax=images&ia=images https://duckduckgo.com/?q=dilbert+random+generator+nine+nine... (couldn't find a good link to the comic)
- 2y ago
- nubinetwork 2y agoI 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).
- homebrewer 2y agoIt is possible, but it's generally not a good idea. https://wiki.archlinux.org/title/Microcode#Late_loading https://wiki.archlinux.org/title/Microcode#Late_loading https://docs.kernel.org/arch/x86/microcode.html#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 https://www.phoronix.com/news/AMD-Late-Loading-Microcode
- rincebrain 2y agoTo 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...)
- dooglius 2y agoDoesn'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.
- rincebrain 2y agoThere'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).
- _rdvw 2y agorecent 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
- eigenform 2y agoThey're trying to validate that you're using a trusted version of AGESA. This is probably intentional, the AMD bulletin[^1] mentions this (ie. for Milan): > Minimum MilanPI_1.0.0.F is required to allow for hot-loading future microcode versions higher than those listed in the PI. Now that runtime loading of microcode patches cannot be implicitly trusted, the machine should not attempt to prove AMD's authorship of the newly-loaded patch without a concrete guarantee that the current microcode patch is trustworthy. Presumably (load-bearing italics), the contents of an AGESA release (which contains the patch applied by your BIOS at boot-time) can be verified in a different way that isn't broken. [^1]: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3019.html https://www.amd.com/en/resources/product-security/bulletin/a...
- garaetjjte 2y agoPrivileged code can load microcode? Duh, "vulnerability".
- ngneer 2y agoThere are multiple privilege levels. Microcode has higher privilege than an OS/VMM does.
- Kab1r 2y agoDoes anyone know if this is the same vulnerability that ASUS leaked in a beta BIOS?
- bri3d 2y agoTo the very best of my knowledge, yes, it is.
- deleted 2y ago[deleted]
- bhaney 2y agoDamn, now all those hostile microcode patches I'm always attempting to load might actually work?
- techwiz137 2y agoHow do they know the internal microcode structure of instructions or even format?
- ris 2y agoSome people are very good at this, e.g. https://app.media.ccc.de/v/35c3-9614-inside_the_amd_microcode_rom https://app.media.ccc.de/v/35c3-9614-inside_the_amd_microcod...
- xmodem 2y agoSecurity implications aside, the ability to load custom microcode onto these chips could have fascinating implications for reverse engineering and understanding them better.
- AnotherGoodName 2y agoAlso 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.
- basementcat 2y agoWhile you’re at it, allow for a few more ulp (units of least place) error for floating point ops.
- basementcat 2y agoKidding aside, my understanding is this sort of thing cannot be microcode patched. But I would be pleased to be proven wrong.
- Lockal 2y agoIt can be patched, see example in "constant-time hardware division" section in https://misc0110.net/files/cpu_woot23.pdf https://misc0110.net/files/cpu_woot23.pdf (code: https://github.com/pietroborrello/CustomProcessingUnit/blob/master/bios/ucode_patches/ctdiv.u https://github.com/pietroborrello/CustomProcessingUnit/blob/...). You probably won't observe any improvement unless you know an algo massively better than reciprocals+newton.
- mindslight 2y agoSecurity 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 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.
- qwertox 2y agoDoes this patch persist across power cycles / reboots?
- nicman23 2y agono
- _rdvw 2y agoReminder 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-amd-official.txt 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-amd.txt 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
- thayne 2y agoHigh seems a bit extreme to me. If you have something malicious running in ring 0, you are already in big trouble.
- ec109685 2y agoThe 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.
- userbinator 2y agoThis reminds me of a decade-old utility called "Bulldozer Conditioner" that claimed to increase performance of certain AMD CPUs dramatically (and was verified by benchmarks), yet the author was extremely avoidant of the technical details of how it was accomplished --- AFAIK no one publicly RE'd and posted information on it that I could find, and I never got around to doing it either, but now I wonder if he had figured out how to modify and optimise(!) the microcode.
- monocasa 2y agoI was curious, so I took a look at Bulldozer Conditioner. It seems it's working by flipping some chicken bits in un(or not very well)documented MSRs. The same kind of registers that were used to disable certain processor optimizations in service to spectre mitigations.
- neuroelectron 2y agoIt would be interesting to have an open source microcode community.
- account42 2y ago"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.
- ZiiS 2y ago"This vulnerability allows a local administrator (ring 0 from outside a VM) to load clean microcode patches free of the vendor's malicious features."
- ChocolateGod 2y agoIf the attacker has ring 0 outside a VM, don't they have full access to the memory and execution state anyway?
- adrian_b 2y agoOn AMD server CPUs, the administrator of the cloud/datacenter is supposed to not have access to the encrypted memory used by customers' VMs. This vulnerability breaks this assumption.
- sylware 2y agoIt is expected for a ring 0 user to be able to load the microcode it wants... no vuln here.
- z3phyr 2y agoAre there any tutorials on writing custom microcode? I imagine it would be like ring0 driver programming on steroids! Pretty cool.