The Mechanism Is the Product

HOST: Welcome back to Stake and Rope, from Goat Security. Today: AMD silently removed a memory encryption feature from its consumer Ryzen chips in a firmware update, users noticed, users complained, and over the weekend AMD said they’d put it back in a July BIOS release. Ars Technica covered it. The feature is called TSME — Transparent Secure Memory Encryption — and it’s been shipping in consumer chips for about a decade. AMD has not explained why they removed it, and they didn’t respond to questions about the reversal either. With me today: the Legacy Sysadmin, who has watched vendors do this exact thing across four decades and several silicon generations. The Paranoid CISO, who’s going to tell us what memory encryption actually protects against and whether we should care. And the DBA, who has opinions about firmware updates that remove features. Goat Farmer’s here too. Sysadmin — what does this remind you of?

LEGACY SYSADMIN: [sighs] It doesn’t remind me of anything. I lived it. This is what IBM did with mainframe microcode in the eighties. You’d buy a machine with a certain feature set, and then a microcode update would land, and suddenly some feature you’d been using for two years required a different model number. The hardware was identical. The silicon was identical. There was a flag somewhere that said you didn’t pay enough.

HOST: And the customer response was?

LEGACY SYSADMIN: The customer response was: pay more. Because what else were you going to do, migrate off System/370 in 1986? Nobody was migrating off anything. You paid.

THE DBA: Sun did it with Solaris. Specific patches that turned features on if you had a service contract, off if you didn’t. Same binary. Same kernel. Different licensing string.

LEGACY SYSADMIN: HP did it with the LaserJets. Postscript was either there or it wasn’t, depending on the SKU, but the silicon was the same chip.

THE DBA: Oracle still does it. You can have a sixteen-core box and they’ll license you for four, and the database will refuse to use the other twelve until you cut a check.

HOST: So the move is old. Let me bring in the CISO. Memory encryption against cold boot attacks — give us the threat model. Who is this actually protecting against?

THE PARANOID CISO: The threat model is narrow but real. Cold boot attacks require physical access to the machine, a window of seconds to minutes after power loss, and equipment to read DRAM contents before the bits decay. In a consumer context — gaming desktop, home office — the realistic adversary pool is small. A burglar isn’t running a cold boot attack. A nation-state operator with physical access to your laptop in a hotel room in Shenzhen is. The feature matters for a specific population: journalists, dissidents, executives traveling to adversarial jurisdictions, anyone whose threat model includes border crossings.

HOST: Which is not most consumer Ryzen buyers.

THE PARANOID CISO: Correct. Most people who bought a 9000-series chip bought it to play games. For them, TSME was a checkbox they probably never thought about and a small latency cost they may have already disabled. The article makes that point and it’s fair.

THE DBA: Then why are we mad about it.

THE PARANOID CISO: Because the removal is the signal, not the feature. AMD shipped a security capability for ten years, removed it silently through firmware, declined to explain, and made the removal undetectable on Windows. That sequence tells you something about how AMD thinks about customer trust and how they make decisions about security features. The feature itself is narrow. The decision-making process is not.

LEGACY SYSADMIN: And the decision-making process is: somebody in a conference room decided this was an upsell lever. There’s a Pro version of the chip. The Pro version still has Memory Guard. You want the security, you pay for the Pro.

THE DBA: [scoffs] Of course.

HOST: Let me push on something. CISO, you said the threat model is narrow. The Ars piece is pretty explicit that consumer chips are rarely targeted by physical attacks. Are we treating this as a security story when it’s really a trust story?

THE PARANOID CISO: [hmm] That’s the right question. I’d say it’s both, but the trust story is the larger one. The security impact of removing TSME from a gaming desktop is, in aggregate, modest. The trust impact of removing a feature silently through firmware after ten years of shipping it — that’s the part with reach. Because the next time AMD ships a firmware update, I have to wonder what else they’re toggling. And so does every enterprise buying their parts. EPYC customers read this story. They saw what AMD does to consumers when nobody’s looking and nobody’s paying enterprise prices. They will draw conclusions.

THE DBA: That’s right.

LEGACY SYSADMIN: That’s the actual damage. Not the gamer who turned TSME off anyway. The Fortune 500 procurement officer who reads Ars and thinks, huh, maybe we should ask AMD some pointed questions about our service agreement.

HOST: Let’s stay with the trust piece for a minute. DBA, you said earlier — the reversal doesn’t fix the underlying problem. Walk me through that.

THE DBA: AMD removed the feature. Users complained. AMD put it back. What’s the underlying problem.

HOST: Tell me.

THE DBA: The underlying problem is that somebody at AMD decided, in a meeting, that this was an acceptable thing to do. That person still works there. The meeting still happens. The next time the meeting happens, the feature that gets removed will be one fewer people noticed, or one that takes longer to detect, or one in a product line where the customer base is less vocal. The reversal here is not a policy change. It is one specific feature being reinstated because the noise was loud enough. The mechanism that produced the removal is intact.

THE PARANOID CISO: The mechanism is the firmware update channel. AMD has demonstrated they can toggle security features through it, silently, with no notification and limited detectability. That capability now exists in the field. The next removal doesn’t require a new mechanism.

LEGACY SYSADMIN: Which is exactly what the microcode update channel was on mainframes. Once the vendor figured out they could change your machine’s behavior remotely, they were never going to stop being able to do that.

GOAT FARMER:

Reason number 63. When you buy a new goat, the goat does not need to re-write registry keys on the farm that could have unforeseen effects on the other animals already residing there.

HOST: Let me ask the harder question. Sysadmin, you’ve been at this for forty years. You’re describing this as standard vendor behavior. But AMD actually reversed course here. Users complained, AMD listened. That is not the usual outcome. Are we being too cynical?

LEGACY SYSADMIN: [pause] No. We’re not being cynical enough. AMD reversed course because they got caught fast and the noise was disproportionate to the feature. The next time, the feature will be one nobody benchmarks. There will be no detection. There will be no Ars piece. The reversal here is the exception. The removal is the rule.

THE DBA: And the reversal is in July. The feature is still gone right now. Anyone who updated their BIOS this month is unprotected for a month and a half. AMD calls that a win because they announced the fix.

HOST: Goat Farmer — you’ve been quiet.

GOAT FARMER: I don’t miss it.

HOST: Don’t miss what?

GOAT FARMER: Any of it.

HOST: Let me bring us to something specific. CISO, you said EPYC customers are watching. The enterprise side of AMD’s business is significant. How does this incident actually move trust calculations at that scale?

THE PARANOID CISO: It depends on the maturity of the buyer. A sophisticated enterprise customer already runs every firmware update through a staging process and diffs the behavior before production deployment. They will catch a silent feature removal. They will catch it months after AMD ships it, because staging cycles are slow, but they will catch it. A less sophisticated buyer — and most are less sophisticated than they think — will not catch it. They will discover the missing feature when something breaks, or when an auditor asks a question they can’t answer.

LEGACY SYSADMIN: This is also why FIPS validation matters. If you have a chip whose security features can be toggled by firmware without revalidation, your FIPS posture is theoretical. AMD just demonstrated that on consumer parts. The enterprise question is whether the same capability exists on the validated parts and whether anyone has tested it.

THE DBA: Somebody has tested it.

THE PARANOID CISO: Somebody has tested it. The question is whether that somebody works for AMD, works for a customer, or works for a foreign intelligence service. The capability is interesting to all three.

HOST: That’s the unsettling read. Let me give us a step back for a second. Sysadmin, you mentioned the mainframe microcode pattern. Take me there for a minute. What does that history actually teach us about where this goes?

LEGACY SYSADMIN: [sighs] In 1988 I worked at a shop that ran a 3090. IBM shipped a microcode update that we applied on a Tuesday night, the way you applied microcode updates. Wednesday morning, our batch window ran twenty percent slower. We called IBM. They told us, very politely, that we had been getting performance from an unlicensed feature for about eighteen months, and the microcode update had closed that gap. They offered to sell us the feature for, I want to say, eighty thousand dollars a year. We paid. There was no other option. The point is not that IBM was evil. IBM was a business. The point is that the moment a vendor has a remote channel into your machine, the relationship is no longer about hardware. It’s about what the vendor decides to let you have today. AMD just learned that lesson works on silicon they already sold. Every chip vendor watched this story. The ones with the same firmware capability — which is all of them — took notes.

HOST: Okay. Let’s land the plane. Closing thoughts. Goat Farmer first.

GOAT FARMER:

Reason number 15. Goats don’t become obsolete. If they do, as long as you didn’t neuter them, they make the necessary upgrades themselves.

GOAT FARMER: Nobody pushes a firmware update to a goat. The goat is the goat you bought. It stays the goat you bought. If it gives less milk one season, that’s the season. It’s not a licensing change.

HOST: Sysadmin.

LEGACY SYSADMIN: This is a forty-year-old move executed on twenty-first-century hardware. IBM in ‘86. Sun in the late ’90s. Oracle ever since. The mechanism changes — microcode, then patch licensing strings, then telemetry-based feature flags, now firmware over the network. The move is the same. Remove a feature you previously shipped. Wait for the complaints. If they’re loud, put it back. If they’re not, never mention it again. AMD ran the play, got caught faster than they expected, and is rolling the reversal out next month. I would not interpret the reversal as a change in their thinking. I would interpret it as a feedback signal that worked once and may not work twice. The next removal will be quieter. It will be in a product line with less attention. It may be a feature that takes a year to be noticed. The move is permanent. The reversal is local.

HOST: CISO.

THE PARANOID CISO: The piece of this that stays with me is the detectability gap. The article notes the removal was impossible to detect on Windows and required significant technical work to detect on Linux. That is not an accident of implementation. That is a property of the firmware-update channel. AMD has — and so does every silicon vendor — a capability to modify the security characteristics of fielded hardware in ways the operating system cannot see and the user cannot inspect. The feature reinstatement does not remove that capability. It demonstrates it works. The next time this happens, and there will be a next time, the question for every defender is: what other feature on the chips in my datacenter has changed since the last firmware update, and how would I know. The honest answer for most organizations is they would not know. That should concern you.

HOST: DBA, you close.

THE DBA: This isn’t a security story. This is a licensing story dressed up as a firmware update. AMD has a Pro version of the chip that costs more. The Pro version has Memory Guard. The consumer version had Memory Guard. Somebody at AMD looked at the SKU spread and decided the consumer version was eating too much of the Pro version’s value proposition. They pulled the feature. They didn’t pull it through a recall or a product refresh. They pulled it through a firmware update because that’s the channel that doesn’t require them to admit anything. They got caught. They’re putting it back. They will not put it back in a way that prevents the next removal. The mechanism is the product. The chip is incidental.

HOST: A vendor decided what you owned was theirs to take back, did it quietly, and we should all be grateful they noticed the noise. We’ll see you next time.