GoKawiilTL;DR: About a decade ago, AMD added Transparent Secure Memory Encryption to its high-end processors to close a gap in hardware security. TSME encrypts everything in RAM, which blunts cold-boot attacks and other hands-on memory exploits targeting data as it sits on the DIMMs. Over time, the same mechanism quietly appeared on some consumer Ryzen chips as well. Then, after a recent firmware update, it stopped working there, and AMD has offered only a limited explanation for why.
The change came to light in April, when Ben Kilpatrick installed a new OS on a Ryzen 7 9700X system built on AMD's Zen 5 architecture. He describes himself as a "privacy-conscious Linux hobbyist," and part of his routine is to verify that hardware security features are switched on. To do that, he uses Host Security ID, a checker that inspects firmware and hardware configuration.
On earlier firmware, HSI had reported that RAM encryption was enabled on his machine. This time, the readout showed "encrypted RAM: not supported," even though TSME was still enabled in the BIOS.
A few lines lower, HSI showed that the same system had previously reported RAM as "encrypted." The mismatch between the BIOS setting and the current status is what prompted him to look for an explanation.
Kilpatrick contacted MSI, which made his motherboard, and pushed for tests across different boards and firmware versions. MSI engineers eventually confirmed that consumer Ryzen CPUs reported TSME as supported when an older version of AGESA, AMD's Generic Encapsulated Software Architecture, handled the firmware path during boot.
When systems booted with AGESA 1.2.7.0, those same chips reported TSME as "not supported." Pro-branded Ryzen parts did not change behavior. They showed TSME support across both MSI and Gigabyte boards and across AGESA revisions.
That pattern suggested the silicon was still capable of TSME and that the shift in behavior was tied to firmware. "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 Technica. In his view, "either way the silicon is capable, either way the change happened in AGESA, and either way AMD has declined to explain it."
To get a more direct answer, he opened a bug report in AMD's public GitHub repository for its secure virtualization and memory features. Two AMD engineers responded. Tom Lendacky, an AMD fellow software engineer, said he did not know what caused the change and suggested toggling the BIOS setting: turn TSME off, then back on, and if that failed "my guess would be that it is a BIOS issue and you would want to contact MSI."
Mario Limonciello, a senior principal software engineer who maintains the fwupd implementation of HSI, gave similar advice: try again at the BIOS level, and if it still doesn't work, "then yes please report it to your board vendor to debug."
By the time Kilpatrick returned to the thread six weeks later, MSI had done more detailed analysis. He reported that MSI's product marketing team told him "that AMD officially communicated to MSI that TSME is exclusively supported on PRO series processors."
... continue reading