TSME/SME not activating on Ryzen 7 9700X (Zen 5) — MSR 0xC0010010 bit 23 remains 0 despite BIOS enable and mem_encrypt=on

[benkilpatrick]

System:

• CPU: AMD Ryzen 7 9700X (Zen 5)
• Motherboard: MSI MPG X870E EDGE TI WIFI
• BIOS: 7E59v1A82 (AGESA 1.3.0.0)
• OS: CachyOS (Arch-based)
• Kernel: 7.0.0-1-cachyos-bore with CONFIG_AMD_MEM_ENCRYPT=y

Description:
TSME is enabled in BIOS (Overclocking → Advanced DRAM Configuration → TSME: Enabled). Despite this, the SME hardware enable bit (bit 23 of SYSCFG MSR 0xC0010010) reads 0 after boot. The sme flag is absent from /proc/cpuinfo. Adding mem_encrypt=on to the kernel cmdline has no effect — the kernel receives the parameter but never activates SME.

Notably, fwupd HSI previously reported Encrypted RAM as "Encrypted" and then on 2026-04-05 transitioned to "Not supported" with no corresponding BIOS update, package update, or any other identifiable system change on that date (confirmed via pacman log and journalctl). This suggests TSME may have stopped functioning at some point prior to investigation, or that fwupd's detection changed. Either way, the MSR confirms the current hardware state is inactive.

Diagnostic output:

# rdmsr -f 23:23 0xC0010010
0

# rdmsr 0xC0010010
740000

# grep sme /proc/cpuinfo
(no output — sme flag absent)

# grep AMD_MEM_ENCRYPT /proc/config.gz (decompressed)
CONFIG_X86_MEM_ENCRYPT=y
CONFIG_AMD_MEM_ENCRYPT=y
CONFIG_ARCH_HAS_MEM_ENCRYPT=y

# dmesg | grep -i sme
[    3.148127]     mem_encrypt=on
(no "AMD Memory Encryption Features active: SME" line)

# fwupdmgr security (HSI)
HSI-4: Encrypted RAM: Not supported
Event log: 2026-04-05 12:47:27 — Encrypted RAM changed: Encrypted → Not supported

Expected behavior:
With TSME enabled in firmware, AGESA should set SYSCFG bit 23 before OS handoff. Alternatively, mem_encrypt=on should allow the kernel to activate SME if the CPUID capability bit is exposed.

Actual behavior:
SYSCFG bit 23 is not set by firmware. The kernel does not detect SME capability via CPUID and silently ignores mem_encrypt=on.

Notes:
This may be an AGESA 1.3.0.0 regression or a Zen 5 consumer SKU limitation in CPUID SME capability reporting. The TSME BIOS option is present and togglable but has no observable effect on the hardware register. The historical fwupd state change with no identifiable trigger may be a useful data point for AMD's investigation. Happy to provide additional diagnostics if helpful.

[tlendacky]

TSME activation does not set the SYS_CFG SMEE bit, it is unrelated to that.

[benkilpatrick]

TSME activation does not set the SYS_CFG SMEE bit, it is unrelated to that.

Thanks for the correction! If TSME activation doesn't set the SYS_CFG SMEE bit, what is the correct way to verify TSME is active from userspace or kernel space? And would you have any insight into why fwupd HSI previously reported Encrypted RAM as active and then transitioned to "Not supported" with no identifiable system change?

Edit to add: Following up with additional diagnostics:

CPUID leaf 0x8000001F reports SME = true, confirming hardware support is present. However, the kernel does not expose the 'sme' flag in /proc/cpuinfo and does not activate SME when mem_encrypt=on is passed on the cmdline - no "AMD Memory Encryption Features active: SME" line appears in dmesg.

fwupd identifies the check as plugin: pci_psp, and the Secure Processor device appears in fwupdmgr get-devices without a firmware version, which may explain the not-supported result.

Could you advise what would prevent the kernel from activating SME when CPUID reports support, and what the correct method is to verify TSME state?

[tlendacky]

TSME activation does not set the SYS_CFG SMEE bit, it is unrelated to that.

Thanks for the correction! If TSME activation doesn't set the SYS_CFG SMEE bit, what is the correct way to verify TSME is active from userspace or kernel space? And would you have any insight into why fwupd HSI previously reported Encrypted RAM as active and then transitioned to "Not supported" with no identifiable system change?

You can search for the "tsme_status" file under /sys. It is associated with the CCP PCI device. I believe it should be available for your CPU, but you will need at least a 6.11 kernel for that support.

Edit to add: Following up with additional diagnostics:

CPUID leaf 0x8000001F reports SME = true, confirming hardware support is present. However, the kernel does not expose the 'sme' flag in /proc/cpuinfo and does not activate SME when mem_encrypt=on is passed on the cmdline - no "AMD Memory Encryption Features active: SME" line appears in dmesg.

The kernel relies on the SMEE bit of the SYS_CFG MSR being set by BIOS/UEFI. Check your BIOS options to see if there is an option to enable SMEE. If your BIOS does not provide such an option, then you won't be able to use SME via the kernel. However, I recommend using TSME over SME, anyway, since everything in DRAM is encrypted with TSME.

fwupd identifies the check as plugin: pci_psp, and the Secure Processor device appears in fwupdmgr get-devices without a firmware version, which may explain the not-supported result.

I'm not familiar with fwupd, so can't really talk to that.

Could you advise what would prevent the kernel from activating SME when CPUID reports support, and what the correct method is to verify TSME state?

[benkilpatrick]

Thank you for taking the time to look into this and give me as much help as you have. I genuinely appreciate it, especially given how much you no doubt have on your plate. I found the tsme_status file as suggested:

/sys/devices/pci0000:00/0000:00:08.1/0000:7b:00.2/tsme_status = 0

This confirms TSME is not active despite being enabled in BIOS (Overclocking > Advanced DRAM Configuration > TSME: Enabled). Is there anything specific we should be looking at in the BIOS or firmware to understand why TSME activation is failing, or is this something that needs to be investigated on AMD's firmware side?

[tlendacky]

Thank you for taking the time to look into this and give me as much help as you have. I genuinely appreciate it, especially given how much you no doubt have on your plate. I found the tsme_status file as suggested:

/sys/devices/pci0000:00/0000:00:08.1/0000:7b:00.2/tsme_status = 0

This confirms TSME is not active despite being enabled in BIOS (Overclocking > Advanced DRAM Configuration > TSME: Enabled). Is there anything specific we should be looking at in the BIOS or firmware to understand why TSME activation is failing, or is this something that needs to be investigated on AMD's firmware side?

I'm not sure what could have caused the change. You could try disabling and re-enabling the option in BIOS to see if that changes things. If that doesn't work, my guess would be that it is a BIOS issue and you would want to contact MSI.

[benkilpatrick]

Thanks! I do have a ticket open with MSI as well.

[superm1]

If tsme_status isn't switching to 1 after enabling it in the BIOS, I would say try reset BIOS defaults and do it once more. If it still doesn't work; then yes please report it to your board vendor to debug.

[benkilpatrick]

Tom, I have a follow-up question. MSI's product marketing team has informed me that AMD officially communicated to MSI that TSME is exclusively supported on PRO series processors. They 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.

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, while the 9945 returns TRUE when TSME is ENABLED. I am attaching that comparison for reference.

You previously confirmed TSME support on a Ryzen 3700X in 2020. Has support changed in newer AGESA versions covering Zen 4 and Zen 5? Is TSME supported on the Ryzen 9700X specifically? Does the DfIsTsmeEnabled flag in the ABL dump reflect a hard restriction at the silicon level, a firmware policy decision in AGESA, or something else? And if it is a firmware policy decision, is there any path to enabling TSME on consumer Zen 5 silicon in a future AGESA update?

[tlendacky]

I'm not aware of what the Ryzen processors are doing these days in relation to TSME. Adding @superm1 to see if he has anything he can communicate in this regard.

[superm1]

"AMD Memory Guard". is available as part of the "Pro technologies".

[benkilpatrick]

@superm1 Thank you for the clarification. To make sure I understand correctly: is TSME on consumer Ryzen (specifically Zen 5 like the 9700X) a hardware limitation at the silicon level, or is it a firmware policy decision in AGESA that restricts activation to PRO SKUs?

The reason I ask is that the ABL dump comparison shared by MSI's BIOS engineer shows DfIsTsmeEnabled returning FALSE for a consumer 9800X3D and TRUE for a PRO 9945, which suggests AGESA is making an active decision based on SKU. If it is a firmware policy rather than a silicon limitation, is there any path to enabling TSME on consumer Zen 5 in a future AGESA update?

[superm1]

Platform Firmware for desktop parts is distributed as part of a "ComboPI". This means that it contains different firmware streams for different parts and will activate the correct microcode containing the correct feature set that goes with the given hardware.

[benkilpatrick]

Platform Firmware for desktop parts is distributed as part of a "ComboPI". This means that it contains different firmware streams for different parts and will activate the correct microcode containing the correct feature set that goes with the given hardware.

Thank you for the explanation of ComboPI. That's helpful context.

One follow-up if you don't mind: based on what you've described, 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.