Users cry foul after AMD stripped memory crypto from its consumer CPUs - Ars Technica
Skip to content
AI
Biz & IT
Cars
Culture
Gaming
Health
Policy
Science
Security
Space
Tech
Forum
Subscribe
Story text
Size
Small<br>Standard<br>Large
Width
Standard<br>Wide
Links
Standard<br>Orange
* Subscribers only
Learn more
Pin to story
Theme
Search
Sign In
Sign in dialog...
Text<br>settings
Story text
Size
Small<br>Standard<br>Large
Width
Standard<br>Wide
Links
Standard<br>Orange
* Subscribers only
Learn more
Minimize to nav
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.
HSI output showing that his Ryzen CPU once provided TSME but no longer does. AMD pulled the feature for consumer CPUs without notice or an easy means for users to know.
Credit:<br>Ben Kilpatrick
HSI output showing that his Ryzen CPU once provided TSME but no longer does. AMD pulled the feature for consumer CPUs without notice or an easy means for users to know.
Credit:
Ben Kilpatrick
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...