The Ryzen AI Max+ 395 silicon supports AMD’s Transparent Secure Memory Encryption (TSME), but the Framework Desktop BIOS doesn’t expose the toggle that enables it.
What TSME does: encrypts all DRAM with an ephemeral key generated by the AMD Secure Processor at boot. The key never leaves silicon. Cold-boot and DMA-based RAM extraction attacks return encrypted bytes instead of useful data. ~2% performance cost per Phoronix testing on the PRO 395 — within run-to-run noise for most workloads.
Evidence the hardware supports it but BIOS keeps it off:
$ grep -o sme /proc/cpuinfo | head -1
sme
$ sudo rdmsr -f 23:23 0xc0010010
0 # MSR_AMD64_SYSCFG bit 23 — BIOS has not enabled SME
The sme CPUID flag is present, so silicon supports it. MSR bit 23 is 0 because BIOS doesn’t enable it. Linux cannot set this bit from userspace or kernel command line — only firmware can. The TSME setting is part of the standard AMD CBS reference code shipped to OEMs; in unmodified reference BIOSes it lives under Advanced > AMD CBS.
Asks:
-
Expose a TSME on/off toggle in the BIOS setup menu (default-on with no UI toggle would also be fine).
-
If AMD’s SKU segmentation fuses TSME off on the consumer (non-PRO) Ryzen AI Max+ 395, confirming that explicitly would save the community time investigating workarounds.
Context:
-
Phoronix’s review of AMD Memory Guard on the PRO 395 shows the feature is essentially transparent in everyday use: https://www.phoronix.com/review/amd-memory-guard-ram-encrypt
-
There’s a parallel Win-Raid community request to unlock the Framework Desktop BIOS more broadly, indicating wider interest: https://winraid.level1techs.com/t/request-unlock-bios-uefi-for-amd-395-strix-halo/111395