High seems a bit extreme to me. If you have something malicious running in ring 0, you are already in big trouble.
AMD: Microcode Signature Verification Vulnerability
81–90 of 107 posts
Re: AMD: Microcode Signature Verification Vulnerability
#82This 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.
Re: AMD: Microcode Signature Verification Vulnerability
#83Earlier 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…
I think you may be overestimating the scale of attack that can be accomplished within the constraints of a microcode update. Given that the CPU has to still seem to be operating normally while using malicious microcode, how much space out of the few kilobytes of a microcode update file is really available for implementing a subtle attack, complete with monitoring the state of the larger system to detect a trigger condition or locate specific information (such as the timestamp you mention)? Sure, malicious microcode theoretically has access to basically everything, but the severely limited payload makes it a lot harder to pull off complicated attacks.
Re: AMD: Microcode Signature Verification Vulnerability
#84Earlier quoted context omitted.
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
They'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/a...
Re: AMD: Microcode Signature Verification Vulnerability
#85Earlier quoted context omitted.
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 s…
Yes, remote attestation is tantamount to the hardware snitching on the execution, and not necessarily to the benefit of the platform owner. I agree with you, that from a game theoretic perspective, as soon as the vast majority of platforms betray user trust, those seeking to use other machines will be left stranded. However, despite the above dynamics, you could still buy any machine you like and use it any way you like, just like app stores have alternatives. You may not like the alternative, but that is a different story.
Knowing nothing about you, it is safe to assume that you may use the dollar or similar currency, either directly or indirectly. Why would you choose to do that? Such currencies come with lots of rules and regulations about what you can and cannot do. Society must keep track of who has how much in banks, and individuals are held liable should there be an overdraft. Remote attestation may certainly put a damper on doing your own thing with your computer, but you can choose whether you wish to pay the price of participating in the economy. Not sure if the above is a great analogy, probably a terrible one, but the bygone ideal of having your computer acting solely in your interest is simply not very realistic. At the very least, controlling the microcode will not give you the control you seek, because there are too many other layers in the stack that are routinely broken, and you are always one exploit away from joining a botnet. No matter how you wish to spin it, your computer is not yours, and obeys many masters. If you feel otherwise, please offer a counterexample to the preceding statement.
Re: AMD: Microcode Signature Verification Vulnerability
#86As 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.
Will the OS fix the microcode, or will a BIOS flash be required?
Re: AMD: Microcode Signature Verification Vulnerability
#87Earlier quoted context omitted.
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
They'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…
interesting!
I suppose a sufficiently older agesa may actually load the newer microcode then if that was a recent addition in preparation for this
Re: AMD: Microcode Signature Verification Vulnerability
#88Earlier quoted context omitted.
That's a reference to the PS3's RNG.
I always thought the same when seeing that XKCD comic, but turns out it was the opposite. PS3 hack (2010) came 3 years after the XKCD comic(2007), they even used it as one of slides during 27C3 presentation. https://media.ccc.de/v/27c3-4087-en-console_hacking_2010#t=2...
Oh my.
Re: AMD: Microcode Signature Verification Vulnerability
#89This 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 figure…
I 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.
Re: AMD: Microcode Signature Verification Vulnerability
#90This 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 figure…
It would be interesting to have an open source microcode community.