Whats with the doom laden tone of the article? I could have written "hackers figure out how to open the management engine, no longer need you be a serf on your own CPU" and it would be just as accurate.
Honestly! From a non-corporate perspective this sort of thing is a welcome development. The constructive concern is whether this might enable coreboot/libreboot on newer generation processors, and if not then whether it's ergonomic enough to at least enable widespread neutering of AMD's built-in trojans.
(PS if you're worried about the illegibility of your computer's storage devices and your resulting inability to completely wipe it and reinstall, then that sounds like a problem with your motherboard!)
> Improper validation in a model specific register (MSR) could allow a malicious program with ring0 access to modify SMM configuration while SMI lock is enabled, potentially leading to arbitrary code execution.
Not offering an opinion either way, but it depends. If you can exploit the kernel, you can probably do whatever you want. But if you manage to exploit the CPU firmware, you can do what you want even after the system is completely wiped.
Whether you think someone is motivated enough to find a kernel exploit that can trigger this issue and then go through the trouble of exploiting not just the kernel but this very specific CPU issue that exists on certain processors is up to you. Is it likely? I'd say no. Is it possible? Yes. Should you care? Yes. Should you lose sleep? Probably not.
The authors of Stuxnet were “motivated enough” and had the means at their disposal to do what they did. I’m just saying, where the motivate and means exist, it’s possible.
I'm not disagreeing with you. That said, Stuxnet was built by a state actor with the motivation to target nuclear industrial equipment, not your media server's Ryzen 3000. It would be an hell of a lot of motivation without obvious payoff to use this vulnerability to, say, make nastier ransomware or steal crypto. The novelty of this exploit is the durability of it (persisting beyond a full wipe), which isn't something your garden-variety malware needs to extract value. If you have ring0, you already won.
If you're a person who needs to be careful about this sort of stuff (e.g., you're Edward Snowden or run Iran's nuclear program), you hopefully are already paying attention. If you are a mere muggle like the rest of us, the risk is probably not high enough for you to get upset.
I don’t think it’s so crazy to think about the fact that tools like this can be both used by, _and designed for the use of_ state actors, whether in actions against other governments or troublesome individuals — for example, Pegasus is not only for state actors.
You’re assuming a domestic state actor, no? I don’t think it’s a positive certainty that e.g. a foreign state will certainly be able to physically access your systems. Of course, I suppose if you send it in to a foreign country for repair, anything can happen.
If properly motivated, I don't think national boundaries are going to stop someone from accessing a physical device. There may be a small list of countries with very good border controls and lack of existing foreign agents. I'd be curious to know which ones fit
Getting into SMM means you can circumvent flash protection, which means you can rewrite the firmware to backdoor the OS on every boot without needing to leave any evidence in the filesystem, which a normal compromise of ring 0 wouldn't. I don't think most people need to worry about this, but if the claims are accurate this is a genuine circumvention of a privilege boundary.
no, that is the whole point of the Secure Encrypted Virtualization hypervisor (and remember, bare-metal is just another guest). Guests should not be able to jump to hypervisor control just because they type sudo, or just because they have physical presence.
this all comes from the work AMD did on the xbox hypervisor, and obviously a console needs to be physically present (sitting in the attacker's living room) and survive a complete compromise of a guest partition (again, potentially including the OS/"bare-metal guest").
well, like it or not that's a real use-case - and not just DRM/anti-cheat but also things like homomorphic encryption. there's lots of interest in being able to do useful things when the owner of the machine might be an attacker, that is an extremely broad and useful primitive to build upon.
secure encrypted virtualization is supposed to be "homomorphic encryption, but in a system we can actually implement/that actually performs decently". obviously it would be reassuring to know that hetzner can't look at your data that you put into the hardware they own, right?
how do you accomplish that if not creating a root-of-trust that's not controlled by the owner of the machine? I don't trust Hetzner to not see my data, but I might be willing to trust AMD. Let AMD hold the key to my VM memory partition, and the hypervisor exists in a different VM memory partition, and its keys don't work in my partition.
Things which break that security model are obviously of huge concern and it feels borderline intentionally-misleading to phrase it as "why would you be concerned about that". The answer is because it's a foundational break in the security model of SEV and the PSP.
I suppose the cloud use-case makes sense, and my reaction was more to the people saying it mattered that they wouldn't fix consumer/desktop processors, where this thing is primarily if not almost exclusively used to undermine the owner.
even for consumers, the existence of a PSP implies that you don’t want that PSP to become compromised. It has the complete ability to fuck with your container instance in any way it wants with no mitigations possible.
You immediately fall into trusting-trust problems around working in an inherently compromised environment where an attacker can manipulate you in arbitrary ways. You think reading a file twice produces the same results? You think adding two numbers or doing an if-statement returns the proper result? Not if the hardware is malicious.
Beyond the broader “should this exist”, once it is a given that it exists, it’s an incredibly powerful weapon and it certainly shouldn’t be left unsecured. This is the thing that can see the true state of memory, hold all the keys, and even just arbitrarily rewrite memory state or processor state. This is god on this system.
The fact that people see that and say “well you’d have to type sudo to permanently own the machine!” as some kind of excuse or downplaying is nuts and wouldn’t be tolerated from any other brand. But AMD always gets extra benefit-of-the-doubt and kid-glove treatment.
When intel gets compromised nobody does the “ok but should we really have a hypervisor ring anyway???” shit. The amount of special pleading people do on behalf of AMD is insane.
And people would never tolerate intel leaving a bunch of hardware exploits unpatched like some of AMD’s exploits have been.
I think people's reaction to e.g. Intel ME and SGX is also "this shouldn't exist on consumer hardware", and it makes perfect sense to be happy about being able to control both as the owner. The owner is supposed to be god on the system. They're supposed to have a sudo that really gives them full power over everything. sudo (on the bare metal ring) is supposed to let the user see the true state of everything, hold all the keys, arbitrarily rewrite memory, etc.
Ever since I heard of TCPA in the early 2000s I was of the opinion that this is technology that undermines the owner's control of their own computer. Back then it even seemed as if that is a move by Microsoft to get rid of Linux, which gladly didn't happen. It has nothing to do wit Intel Vs AMD. At all.
It has nothing to do with AMD vs Intel. I'm glad if these things become "compromised" in both cases because they're designed to undermine the owner. They shouldn't be on consumer chips, and if they don't actually do what they say, great! Control can be restored to the person to whom it belongs.
I'm also happy that you can get a cheap converter to plug your Ryobi batteries into your DeWalt drill, breaking their anti-consumer "features". Likewise with third party printer ink. All good stuff.
Weird how first the article downplays this because you supposedly need so much privilege to exploit this bug and then they point out that you need to have kernel privileges.
So that’s pretty bad. Kernel exploits aren’t that hard to find and it looks like this bug gives a path from kernel exploit to exploit persistence, with the only way to get rid of the persisted exploit is to throw away the CPU.
SMM shouldn't let you modify any persistent CPU-level state - SMM is slightly magic, but not that magic. It could absolutely allow modification of motherboard-level firmware, but that's repairable given enough enthusiasm.
Isn't the question whether a firmware / BIOS / microcode invasion is detectable given that the firmware has been taken over? The answer being probably not. Except for reading the flash memory at the chip level which is most likely not provided off the shelf by the system. To be repaired, the problem needs to be noticed first.
Platform Secure Boot will measure the firmware into the TPM, so if an attacker modifies the firmware then yes, it'll be detectable. The microcode is signed so any attempt to modify it will simply result in the CPU booting with its ROM-based microcode.
We'll get more detail tomorrow from Defcon - as to where the flaw is located. Apparently something in that neighborhood allows persistence - and for the attack not to be reported.
The shape of the flaw seems pretty clearly described in the abstract - it's the ability to either modify the contents of the locked SMM memory regions (and so get arbitrary code execution there), or trigger SMM execution of code outside the SMRAM region. Either way, SMM vulnerabilities aren't new, and the capabilities associated with them are pretty well understood - what's different here is that the vulnerability is apparently in the CPU rather than the firmware, and so everyone's affected no matter who their firmware vendor is.
SMM is merely a macguffin in this situation, it’s a tool to get the system into a privileged mode whereupon you buffer overflow it with a mailbox message or something. I’d really think that based on your username you have to already be aware of this?
Similar mechanisms were demoed in the ryzenfall exploit series like 5+ years ago.
You don't need to do that if you're able to just shove arbitrary code into SMM in the first place, which is what's supposedly happening here. But having SMM doesn't let you change any persistent CPU state - the set of additional privileges that SMM has is known, and basically comes down to "Can read and write SMRAM, trap certain hardware accesses, and write to protected areas of firmware flash". Nothing in SMM is going to allow you to backdoor the CPU itself so badly that you have to discard it.
SMM is implemented as part of the PSP (again, see the link in the previous comment) and yes, writing to protected areas of firmware flash is the point.
using SMM calls to jump to arbitrary code execution/control of the PSP is a big deal, that’s what happened before and probably what’s happened here.
You've got that the wrong way around - the PSP is able to access arbitrary areas of physical memory that can only otherwise be accessed via SMM, and so compromising the PSP gives you the ability to tamper with SMM code (as discussed in https://blog.trailofbits.com/2018/03/15/amd-flaws-technical-...). Having access to SMM doesn't give you access to the PSP, and being able to modify flash doesn't circumvent Platform Secure Boot. Power off the board and the CPU will return to exactly the state it left the factory in.
I'm not sure if the linked pages was updated recently, if I'm completely misreading it or if you're trolling. There's only one processor family (matisse) that's documented as "no fix planned). All datacenter products already have a fix published, and all non-matisse chips will have a new firmware available by october 2024
The Ryzen 3000 series ("matisse") is less than 5 years old, with the models coming out in late 2019 and 2020. To not issue a fix for those is very disappointing.
I just built a gaming PC with a Ryzen 3600. It is more than sufficient to run modern games with demanding graphics and performance. I now need to learn about this exploit. Yes, if someone gets the level of access required to exploit it I was pwned anyway, but now if I get pwned I need to open up my computer and throw away a perfectly powerful CPU, then put it back together with a new one.
That's pretty damn frustrating. It will definitely push me away from AMD when I am making future hardware decision.
EDIT: As pointed out by sqeaky and others, there shouldn't be a method for persistence that lives on the processor, instead it would likely be on the motherboard, or in the bootloader on a storage device.
We need more details before claiming that the sky is falling. Many exploits that are theoretically possible have so many pre-requisites in practice that they don't matter. We need to see if that's the case here.
Intel CPUs have been self-destructing, so you need to throw away CPUs even if they aren't pwned. They have also had far more security vulnerabilities than AMD, some of them cannot be patched, and operating systems had to work around them. Heck, the Sinkclose name came from 'Sinkhole', which was an Intel vulnerability.
Yes, fair enough. My hasty anger was emotionally driven because I just built a fairly powerful gaming computer with a Ryzen 3600, and because I am perpetually chafed by the hardware treadmill. I still think "no fix planned" for their CPUs that are widely used and <5 years old is ridiculous.
> As a matter of fact, the researchers say that the code would likely survive a complete reinstallation of the operating system. The best option for infected computers would be a one-way ticket to the trash heap.
> In fact, for any machine with one of the vulnerable AMD chips, the IOActive researchers warn that an attacker could infect the computer with malware known as a “bootkit” that evades antivirus tools and is potentially invisible to the operating system, while offering a hacker full access to tamper with the machine and surveil its activity. For systems with certain faulty configurations in how a computer maker implemented AMD's security feature known as Platform Secure Boot—which the researchers warn encompasses the large majority of the systems they tested—a malware infection installed via Sinkclose could be harder yet to detect or remediate, they say, surviving even a reinstallation of the operating system.
> Only opening a computer's case, physically connecting directly to a certain portion of its memory chips with a hardware-based programming tool known as SPI Flash programmer and meticulously scouring the memory would allow the malware to be removed, Okupski says. Nissim sums up that worst-case scenario in more practical terms: “You basically have to throw your computer away.”
I have no information that conflicts with what you posted but none of that indicates that the CPU gets written to.
Consider that even things like CPU microcode don't get stored on the CPU, it's simply doesn't have persistent storage. CPU microcode is often applied early during OS boots and loaded into memory or CPU cache.
What you have quoted indicates something similar, perhaps the main board or other device with storage of some kind is being written to or perhaps an attacker could write a payload that lived entirely in the bootloader on the main storage.
Not 100% true - a microcode-based CPU without microcode isn't able to execute anything, so CPUs will ship with an early version of the microcode that's then (as you say) updated during boot.
They could potentially do that to motherboards, but they could do that anyway (physical access would give you as much access to flash as this vulnerability does). But yes, CPUs should be fine in that respect.
Appreciate the clarification, that makes sense. Maybe we'll get more details on potential persistence methods from the talk they'll give tomorrow: https://info.defcon.org/event/?id=54863
That just sounds like they can install a rogue bootloader, bypass secureboot, or hide from the operating system by operating on a higher privilege level than it. I don't see how it can infect the CPU itself, or how the infection can persist after swapping out the hard drives.
If you get code execution in SMM you can flash the BIOS on the motherboard. You'd be junking the mobo (unless it has one of those "BIOS Flashback" setups), not the CPU.
The "No fix planned" is specifically for just the Ryzen 3000 desktop series. While obviously a fix would be better, given the age of this series as well as the need for ring 0 access to exploit the vulnerability, the actual impact from leaving it unfixed on those CPUs will probably be pretty limited.
I know more than one person running a Ryzen 3700X (launched 7/7/2019) or similar and it's still a perfectly solid CPU.
There are at least upgrade options compatible with the same socket, unlike a certain other CPU manufacturer, but it's not like these are really worth replacing yet.
UserBenchmark scores the 5800x3d about 17% higher for $340.
I am still running a 3600X. Zero reason to upgrade, the CPU has not been a bottleneck on anything I can throw at it. And if I do need to upgrade, that means new motherboard and memory too.
Still over $200 for something that doesn't need an upgrade except for this unpatched security issue. I can think of a lot of other things I'd rather do with $200.
At minimum, save it toward a GPU upgrade that would actually be useful, rather than replacing my CPU that isn't a performance bottleneck.
It's from the Jul 2019. Not very old. CPUs from the early 2010s, with enough ram, are still perfectly usable for light browsing and text editing tasks.
Calling 3900 “very old” is stretching it, but they’re certainly “old”.
Chips from the early 2010s are very old and inefficient - it’s just that you listed tasks that demand nothing, and if battery power is not required it will certainly do the trick.
Being very old and being usable are very things, as any senior person or tech collector will tell you.
> Calling 3900 “very old” is stretching it, but they’re certainly “old”.
No, I will contest <5 years old CPUs being called "old". This perspective is warped by the marketing teams of computer hardware companies. There are many 3000 series processors which are perfectly powerful enough for powerful modern software.
To nitpick, they are not “<5 years”, they are officially more than 5 years and one month old depending on the model. They have been superseded 3 times (5000, 7000 and now 9000), fallen off comparison charts. Even 5000 to 9000 nets you 2x real-world performance for the same power, 3000 was slower and hungrier than that.
There is nothing wrong with using or intentionally buying old things that work. But being “powerful enough to run modern software” doesn’t mean more than “is AMD64 and support a minimum of 8GB of RAM”. I also have a 3rd gen intel i7’s laptop that is “powerful enough to run modern software”, but it’s still very old and incredibly power hungry for the little work it does. I also have a 14 year old car that performs its functions as well as when it was new - much to my dismay - but it’s still objectively old.
If we're nitpicking, then the some were released in July 2019, some were released in October 2019, and some in 2020. And practically, if the earliest they were shipping was July 2019, the wide majority of owners will have had the unit for <5 years.
> But being “powerful enough to run modern software” doesn’t mean more than “is AMD64 and support a minimum of 8GB of RAM”. I also have a 3rd gen intel i7’s laptop that is “powerful enough to run modern software”, but it’s still very old and incredibly power hungry for the little work it does.
If the hardware can run just fine, what makes it old? Why call it old? Increased power efficiency? That is a good thing to strive for, but from a carbon emissions perspective, most computers cost much more carbon to manufacture than to operate across their lifespan.
> I also have a 14 year old car that performs its functions as well as when it was new - much to my dismay - but it’s still objectively old.
It isn't "objectively" old. "Old" does not have an objective definition. I also have a 14 year old car, that I do not consider to be old. I don't consider it to be old because it functions well, matches the aesthetic style of the majority of cars on the road, and getting maintenance on it is easy, as the wide majority of mechanics will be familiar with it. Sounds like your car is in the same boat as mine.
That you consider a 5 year old processor and a 14 year old car to be old is a reflection of your own opinions. I do not agree and think that perspective is consumerist, exactly what corporations spend lots of money to try and make people think.
> the wide majority of owners will have had the unit for <5 years.
No one cares about how long you had the CPU in your possession, nor are we worried about the silicon expiring. If you restarted the factory line and got a brand new chip today, it would still be considered 5 years and 1 month old. Like finding a factory-sealed retro console.
> If the hardware can run just fine, what makes it old?
When something is "old" is context specific, related to how fast the world moves away from it.
To give some easily digestable examples:" A 1 year old person is very young, a 1-year old ant is very old. A 70-year old CEO is old, but might perform the best they ever have in their entire life. A 50-year old car is old, but fully compatible with modern roads and fuels (depending on spec). Despite no formal definition, these are quite objective in that no-one not playing devils advocate could possibly disagree.
For chips, they are old after 4-5 years because the chip world moves fast. This chip has been superseded many times (a great-grandparent at this point), is in the bargain bin as of late last year at somewhere between 1/3rd and 1/6th the price depending on ongoing sales as shops clear unwanted deprecated stock, and now does the work in more than twice the time and with more than twice the energy than the current product in its own line. No one would reasonably look at this side by side with the current offering and think "that's not old!".
(Note: Pre-Ryzen and Apple silicon, the "time to old" was longer because Intel's monopoly and laziness had caused complete stagnation within desktop CPU development, which is what we have grown sued to.)
Buying an old chip is done for the same reasons as buying an old car: If you don't really need it much, it also can't bring you a lot of value and so something something brand new won't mean much to you. Getting a bargain on something old and/or used is great. Whether it is a chip or a car, efficiency doesn't matter if its mostly off anyway. And just like any NES plays NES games as well as it did from day one, the old car if serviced still does the same job it did when it was new.
> It isn't "objectively" old. "Old" does not have an objective definition.
If you believed this, it would invalidate your entire line of argument that the chip (and your car) cannot be considered old as age cannot be classified and is irrelevant: considering the chip not old is therefore also wrong.
Considering that you are specifically attacking the idea of considering the old with the idea that their useful life should be longer, completely ignoring that I mention that devices can be used irrespective of their age, I do not think you actually believe that the age should not be classified. At the same time, if you did not think it was objective, your argument would have focused on saying it was subjective or context-specific rather than saying the classification was wrong.
> that perspective is consumerist, exactly what corporations spend lots of money to try and make people think.
That consumerism is also why the chip is a bargain and new chips are affordable, and the only argument for buying an EOL chip is price. Having any sort of used market for things that get better with time requires people to often buy new things and get rid of old things. Having new things be affordable for anyone requires a significant churn.
> a carbon emissions perspective ...
... is not relevant as I make it very clear that being old does not mean it needs to be replaced. Even if it ends its service life with you, a responsible person would sell it or give it away so someone else can use it instead of buying new.
> No one would reasonably look at this side by side with the current offering and think "that's not old!".
That is exactly what I did a short time ago when I was building a PC and deciding on parts for it. I thought it seemed like a perfectly reasonable option, given that:
1. It was readily available
2. Many other people were building computers with it, or recommending it for builds
3. I judged that it would function well and be compatible with the other hardware in the PC
You are letting the pace at which a company releases new products define what makes something "old" to you. Even if the model that is several releases "old" came out 5 years ago, still functions well and can be used effectively with the software and hardware coming out right now.
It's "old" because the company has released newer versions? It's "old" because it's less expensive? And because it is "old", according to actions taken by the company, it should not be supported, or repaired if there is fault with it? This is clearly exactly what companies want from their consumers to extract as much money as possible from them, and a recipe for massive consumption.
> Buying an old chip is done for the same reasons as buying an old car: If you don't really need it much, it also can't bring you a lot of value and so something something brand new won't mean much to you.
I don't understand. I do need a car, and my car from 14 years ago provides me tons of value. As does my main laptop computer from 6 years ago. I need that computer to make my living doing programming and IT work, and it does a fantastic job of it.
> If you believed this, it would invalidate your entire line of argument that the chip (and your car) cannot be considered old as age cannot be classified and is irrelevant: considering the chip not old is therefore also wrong.
To not have an objective definition does not mean that it means nothing, it means it has a subjective definition. We are disagreeing on our subjective definitions of "old" in this context, and I am saying that your definition leads to negative effects.
> I do not think you actually believe that the age should not be classified. At the same time, if you did not think it was objective, your argument would have focused on saying it was subjective or context-specific rather than saying the classification was wrong.
Yes, I was saying that it has a subjective definition. I thought "does not have an objective definition" in this context implied "has a subjective definition", not "has no meaning and classification of age is impossible".
> That consumerism is also why the chip is a bargain and new chips are affordable, and the only argument for buying an EOL chip is price.
What about all the people who bought the chip at full price 4-5 years ago? They're SOL the same as I am. And I didn't think it was EOL, and don't think it should be. There's no official EOL in the sense "this is how long we'll support this desktop CPU for before it stops receiving security updates". The only reason to believe that it wouldn't receive an update to fix a vulnerability several months later would've been a hazy guess, were I more tuned in to the CPU market. I believe in consumer protection laws that mandate support of products and repair of serious flaws for a longer period.
In terms of reasons for not keeping up with the Joneses: carbon emissions, slowing consumption, keeping things from the junk pile. These are immensely important.
> is not relevant as I make it very clear that being old does not mean it needs to be replaced. Even if it ends its service life with you, a responsible person would sell it or give it away so someone else can use it instead of buying new.
This whole discussion is about a flaw in the chip that leaves a serious vulnerability open. The problem is that if you are risk-averse, or sensitive to cyberattacks, it does need to be replaced. And as the chip could be unsafe, it can't (safely) just be handed off to someone else to use.
This isn't about free updates or improvements. It's about fixing a fixable flaw that leaves open a serious vulnerability that enables persistent infection of a computer. Few people will be capable of making a proper assessment of the risk, even among devs and IT folk.
I still have an i5 2500k chugging along being able to do everything that isn't a heavy workload with ease. This kind of exploit for a CPU that is only 5 years old not getting a fix is embarrassing and shameful.
Yes, all of that but.. that's exactly the way of looking at things that a chip company like AMD are not allowed to have ( or at least to say publicly ).
The CPUs are "old" they are "limit" as an installed base but only comparing to today's AMD market share because I'm pretty sure there are hundred of thousands ( if not a few millions ) of these CPUs all over the World.
My main point is: going the extra-mile/cost to fix these cpus would be the cheaper route for them because image and credibility matters.. a lot.
I bought my 3900x just under 5 years ago. Norwegian consumer protection laws give me 5 years where the producer is required to fix any defects that came with the product.
As this bug now has become known to always have been there, i could probably force amd to replace my 3900x if they don't provide software patches.
Has anyone else attempted a similar RTM for software defects?
Why? I'm anal about security and this barely registers with me but not as something to be angry about.
Somebody with ring 0 privileges (a prereq for this) on your CPU already has root and you have to presume they've already had the ability to write to your BIOS and VBIOS, and this is just confirmation of that. If you're actually worried about this stuff then how can you be sure that someone hasn't paid Microsoft to put stuff into your firmware?
Step 1: Lease a Server for a month
Step 2: Compromise that server
Step 3: Cancel the lease
Step 4: Wait for it to be reused
Step 5: Next Customer in line is now compromised
This isn't catastrophic this is clickbait bullshit. The attacker needs ring 0 privileges, this enables someone with kernel level access to right to the firmware. That's not good, but it's not catastrophic either
Can someone explain how the persistence can work as described here? I thought the CPU microcode was stored in the BIOS, and the CPU itself doesn’t have a persistent memory. Wouldn’t I have to exchange the Motherboard and not the CPU if I was infected by this? Or just reflash the BIOS, assuming the corrupted BIOS doesn’t somehow prevent BIOS flashing?
Edit after looking it up (leaving this comment in case someone else has the same question): Apparently microcode is in fact stored in the CPU itself and it does have permanent storage. The BIOS is only used for updating this internal memory and doesn’t transfer the microcode on every boot. I still wonder if the microcode patches are somehow validated/signed though, otherwise everyone with a kernel exploit could issue update commands to the BIOS with malicious microcode content?
The microcode store in the CPU itself shouldn't be writable (if it were we wouldn't need to load microcode updates from the firmware or the OS on every boot), but there needs to be some microcode on there for the CPU to be able to execute the firmware code that updates the microcode. And yes, microcode is signed (and typically also encrypted). SMM shouldn't have any special level of access to the microcode, any persistence here is likely via the system firmware (which should, as a result, be caught by Platform Secure Boot on platforms where that's enabled)
Yes, probably - but don't forget that the normal user way of 'reflashing the BIOS' is to tell the BIOS to reflash a new image; so in theory (but hard) a malicious BIOS could keep itself in there. If you used JTAG etc to reflash the BIOS externally then yes you could probably clear it out.
Some (most?) motherboards now have a way to reflash a bios in "no POST" scenarios. There's either a dedicated microcontroller or it reuses the embedded controller to read a BIOS image from a USB mass storage device.
Where would exploit code persist? In the BIOS EEPROM? Are Dual-BIOS motherboards such as from Gigabyte (which can re-flash the BIOS from a read-only copy on a second chip) a viable recovery option for a system which has been infested using this attack?
Persists in BIOS flash most likely - that's the writeable place. Re-flashable if the invaded BIOS even tells you that it's been changed (why would it?). And then if it lets you reflash (why would it). Let you switch to the 2nd BIOS perhaps (why would it?). You might reflash by going straight to the flash memory pins but only if you could tell that you need to - or if you are paranoid enough and have the means.
>They don't want to fix this for Ryzen 3000 desktop CPUs. [...]
>How is a compromised AMD CPU better than Intel's CPUs which get damaged due to oxidation and high voltage?
From a sibling comment:
>Improper validation in a model specific register (MSR) could allow a malicious program with ring0 access
For the typical desktop scenario, this is a nothingaburger because it's already game over if malicious code can get any sort of access[1]. It might matter more for server providers because their customers can execute arbitrary ring0 code in guest VMs, but it's unclear whether it affects that or not.
Having security bugs isn't great, but in this case having hardware degradation leading to performance loss and/or crashing is much noticeable.
We need heavy-handed laws mandating that any firmware included with hardware sold must be accompanied by source code, documentation to interfaces, and can be flashed by any person in legal possession/ownership of the hardware. And, that any cryptographic keys for such are not "fused in" so they can be changed with appropriate physical access (and optionally sealed with tamper-evident material).
There's no valid reason to not have this law. Any "intellectual property" excuses aren't going to fly, everyone already knows they're bullshit.
The "NSA backdoor" is the vulnerabilities we found along the way. It's almost certainly either bad firmware code or bad hardware design. Well, to be clear, SMM is bad hardware design, but still...
I’ve always kept the dedicated BMC network port locked down out of paranoia, but this seems to be an exploit that a rogue BMC or BIOS could use to access the host networking stack.
