Skip to content

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

@benkilpatrick

Description

@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.

Activity

tlendacky

tlendacky commented on Apr 24, 2026

@tlendacky
Collaborator

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

benkilpatrick

benkilpatrick commented on Apr 24, 2026

@benkilpatrick
Author

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

tlendacky commented on Apr 25, 2026

@tlendacky
Collaborator

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

benkilpatrick commented on Apr 25, 2026

@benkilpatrick
Author

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

tlendacky commented on Apr 25, 2026

@tlendacky
Collaborator

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

benkilpatrick commented on Apr 25, 2026

@benkilpatrick
Author

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

superm1

superm1 commented on Apr 25, 2026

@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

benkilpatrick commented on Jun 3, 2026

@benkilpatrick
Author

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?

Image
tlendacky

tlendacky commented on Jun 4, 2026

@tlendacky
Collaborator

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

superm1 commented on Jun 4, 2026

@superm1

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

benkilpatrick

benkilpatrick commented on Jun 4, 2026

@benkilpatrick
Author

@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

superm1 commented on Jun 4, 2026

@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

benkilpatrick commented on Jun 4, 2026

@benkilpatrick
Author

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.

superm1

superm1 commented on Jun 4, 2026

@superm1

My apologies; but I don't have any more information to share on this topic.

matthiasfostel

matthiasfostel commented on Jun 17, 2026

@matthiasfostel

This user mistakenly believes the 9700X (and all consumer AMD processors) has TSME support because they did not understand the 3700x mentioned in another thread (#1 (comment)) was referencing the Pro variant. This belief seems to have been caused by a BIOS bug from their motherboard manufacturer that misled them by allowing the setting to be turned on.

Under this misunderstanding, they reached out to Dan Goodwin of ArsTechnica who is running a rage-bait piece making it seem like AMD is retroactively disabling a feature on all their consumer CPUs.

To anyone reading this thread from the article and all subsequent articles picking up the mistake, the AMD Ryzen 7 9700X at no point had TSME support.

Edit: I am not an AMD employee but an AMD user that noticed the errors in the reporting and wanted to set the record straight. I apologize if this violated any rules for this repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @superm1@matthiasfostel@benkilpatrick@tlendacky

        Issue actions