Users cry foul after AMD stripped memory crypto from its consumer CPUs

AMD’s stripping of TSME from consumer CPUs appears to be a deliberate, covert move.

A decade ago, AMD added a protection to its high-end CPUs to protect them against cold boot attacks and other types of physical exploits that siphon sensitive data out of the connected memory chips. Short for Transparent Secure Memory Encryption, TSME encrypts the entire contents stored in memory, making the data useless to physical attackers.

Over time, AMD added TSME to lower-end processors, including the consumer version of its Ryzen chips, a CPU that costs less than the Pro version. Over the years, users of these lower-end chips have gotten used to the added security. Recently and without warning or notice, this lower-end line of AMD chips suddenly dropped the protection, and did so in a way that was impossible to detect on Windows machines and required a fair amount of technical work when using Linux.

Now you see it, now you don’t

AMD has yet to say why TSME worked on these CPUs, or even to confirm the change. AMD declined to answer questions sent by email other than to say TSME “is a security feature only applied to PRO CPUs as part of AMD PRO Technologies.” The statement is the first known time the chipmaker has explicitly made this restriction public.

In April, Ben Kilpatrick, who describes himself as a “privacy-conscious Linux hobbyist,” was installing a new OS on his machine running a Ryzen 7 9700X from the Zen 5 architecture. To check that all security protections were enabled, he had his machine run Host Security ID (HSI), an auditing feature that evaluates the firmware and hardware security configurations.

To his surprise, HSI showed TSME was no longer possible, as indicated by the “encrypted RAM: not supported” line near the bottom of the screenshot below. A few lines lower, the HSI indicates that previously, TSME had shown as “encrypted.” This made no sense to Kilpatrick because he had enabled TSME in his BIOS settings all along.

This sent Kilpatrick into a monthslong investigation to figure out what had happened. After sending an inquiry to both the support and engineering teams at MSI, the manufacturer of his motherboard, he finally convinced company engineers to run tests.

They found that consumer versions of Ryzen running on MSI and Gigabyte motherboards had TSME enabled when an older firmware version, available exclusively through the AMD Generic Encapsulated Software Architecture (AGESA), described here, was used during the boot process. When the firmware in a newer AGESA, specifically version 1.2.7.0, ran instead, TSME showed as “not supported.” Pro versions of the Ryzen CPU supported TSME across both motherboards and AGESA versions.

“The big outstanding question is whether this is a deliberate policy decision by AMD to restrict TSME to PRO chips, or an unintentional regression that was introduced in AGESA 1.2.7.0,” Kilpatrick told Ars. He continued:

The reason that distinction matters is that if it is deliberate policy, AMD made a conscious decision to remove a working feature from consumer hardware and restrict it to enterprise customers. If it is an accidental regression, it is a firmware bug that AMD should fix. Either way the silicon is capable, either way the change happened in AGESA, and either way AMD has declined to explain it. But the two scenarios imply very different things about exactly what happened.

As part of his investigation, Killpatrick filed a bug report on AMD’s public engineering GitHub repository. Two AMD engineers engaged directly.

Tom Lendacky, an AMD fellow software engineer, replied that he didn’t know what caused the change. He suggested disabling and then re-enabling the option in the BIOS. “If that doesn’t work, my guess would be that it is a BIOS issue and you would want to contact MSI,” (It was this suggestion that led Kilpatrick to prevail upon MSI engineers to run the tests mentioned earlier.)

Mario Limonciello, AMD senior principal software engineer and maintainer of the fwupd version of HSI, then chimed in. He, too, suggested disabling and re-enabling the BIOS settings. “If it still doesn’t work; then yes please report it to your board vendor to debug,” he said.

I have nothing more to share, AMD engineer says

Six weeks later, Kilpatrick resumed the discussion. After getting the results of MSI’s investigations, he reported them to the AMD engineers.

“MSI’s product marketing team has informed me that AMD officially communicated to MSI that TSME is exclusively supported on PRO series processors,” he wrote. “They [MSI support personnel] also conducted controlled testing on an Asus X870E motherboard with a Ryzen 9800X3D (consumer) and a Ryzen 9945 (PRO), finding tsme_status = 1 on the PRO processor and tsme_status = 0 on the consumer processor with the same board and BIOS.”

A setting of 1 indicated TSME was enabled. A status of 0 meant it was off.

Next, Kilpatrick turned the engineers’ attention to results from memory captures from the AMD Boot Loader. Typically abbreviated as ABL, it’s a component within AGESA that initializes the hardware prior to the OS loading. MSI’s engineering team found that a string indicating the status of TSME early in the boot process was never enabled.

The memory capture showed that DfIsTsmeEnabled, an internal AGESA flag that controls whether TSME is activated during the firmware initialization process, showed that it was not turned on. The ABL memory dump comparisons returned different values depending on whether the Pro or consumer CPU version was used. The flag showed FALSE for consumer processors and TRUE for PRO or EPYC processors when TSME was enabled in the BIOS.

“Their BIOS engineer also provided ABL dump comparisons showing DfIsTsmeEnabled returning FALSE for the 9800X3D regardless of whether TSME is set to AUTO or ENABLED in BIOS,” Kilpatrick reported, “while the 9945 returns TRUE when TSME is ENABLED.”

Kilpatrick went on in the thread to remind Lendacky that in 2020, the engineer had confirmed TSME was supported on a Ryzen 3700X (a consumer CPU). After more back-and-forth discussion, Kilpatrick asked bluntly: “is DfIsTsmeEnabled being set to FALSE on consumer SKUs a silicon-level limitation, or is it a firmware policy decision within AGESA? The distinction matters quite a bit from a user perspective, since one is fixed and the other is potentially changeable.”

Limoncello promptly replied: “My apologies; but I don’t have any more information to share on this topic.” With that, the discussion and Kilpatrick’s inquiry were over.

The Lendacky comment in 2020 Kilpatrick referred to came in this thread discussing encryption features available in AMD CPUs. Lendacky said that the Ryzen 3700x, a consumer CPU, “should support TSME.” In a 2025 comment in the same thread, the engineer followed up on his comment concerning the 3700x.

“I recommend using TSME (Transparent SME), but it is a BIOS option that needs to be exposed by your BIOS provider,” Lendacky said in response to the question about the consumer chip.

There’s no indication that AMD ever advertised or marketed TSME as being available in consumer CPUs. AMD has long said that a related memory protection, Secure Memory Encryption (SME), is available only in the Pro and Epyc CPU tiers. SME is OS-managed. It uses a single key and allows the OS to selectively encrypt individual memory pages. TSME is firmware-managed. It encrypts all RAM with no OS involvement. When active, it provides protection against physical attacks, including cold boot exploits, DRAM interface snooping, and memory module removal. It activates silently when enabled in the BIOS, making it the more practically useful of the two protections.

AMD engineers’ comments, such as those mentioned above, and the years of TSME working just fine in the lower-cost tier processors, have understandably conditioned Kilpatrick and other users to reasonably regard it as an expected part of the chip package. AMD quietly removing it and providing no acknowledgment or explanation strikes these users as something of a betrayal.

“They could have not realized they did it leading to their cagey responses, or they could have done it intentionally and tried to get away with it, leading to the same cagey responses,” Joe Fitzgerald, an expert in silicon-level security, said in an interview, referring to AMD’s potential motivations for withdrawing TSME. “But I really feel like an explanation should be in order, even if it was ‘TSME was never supposed to be supported. We did ship some firmwares that erroneously enabled it, but you shouldn’t use them since we can’t guarantee it’ll work properly.’”