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.
This. Non-PRO Ryzen hardware has all the fun security and management silicon fused off. While the PRO shares the same silicon, it is binned to higher specs and has all the features functional. Non-PRO chips often have defects in some of the management or enhanced security silicon. Other fused-off features might include advanced DMA, MIMO, DRAM timing, and ECC RAM capabilities, depending on the SKU. The per-unit price for the PRO SKU is usually notably higher than the consumer SKU and is targeted for enterprise machines.
I’d separate two things here: the `sme` flag only says the CPU advertises SME support, while bit 23 in `MSR_AMD64_SYSCFG` tells you whether firmware actually turned memory encryption on for this boot. So I think the useful Framework answer would be whether the non-PRO AI Max 395 has TSME fused/segmented off, or whether the CBS option is just hidden in their BIOS build. If it is SKU-disabled, documenting that explicitly would save people chasing kernel parameters that cannot enable it.
I think this issue is going to go viral.
For example, I know a company that cannot sell old laptops after they have been refreshed with new laptops. They literally have to shred the whole laptop and send it to landfill.
The reason is:
It takes too long (labour expense) to remove the SSD.
It takes too long (labour expense) to remove the RAM.
This ensures no company private data leaks.
If they could have self encrypting SSD and encrypting RAM, they could then not have to remove the SSD and RAM.
TSME was a major positive point, because they might then be able to recycle the laptops and save on landfill and the environment.
So, maybe said business has purchased thousands of AMD laptops, because their security department have tested that TSME works on them, only now to find out it has stopped working.
… I see a lot of bad publicity and upset business customers and environmental activists going postal against AMD over this.
Has there actually been any instance of data being recovered from powered off dram after more than like a day (I know you can freeze it to get a few seconds to maybe minutes)? This thread model seems kind of forced and whoever has this is probably also not satisfied with encryption=destruction.
Would a dd if=/dev/urandom of=/dev/nvme0n1 bs=1M count=<drive capacity>, run a couple times, ensuring no TRIM, (e.g. booted off a custom USB stick that IT maintains) take care of that on a modern SSD?
Edit: I guess the spare cells (and however those are logically mapped by the drive firmware) can theoretically escape this. No NVMe “nuke this drive contents” command?
More edit: I guess there’s nvme sanitize but you have to trust the firmware, and “All Firmware Sucks”™. Bummer.
Not certifiably as there could still be data on spare/retired sectors and stuff, all very theoretical but for the kinds of companies that destroy ram for data reasons that would be enough to not considder that.
Most modern ssds even have a secure erase command in the first place. Also triming the whole drive also is kinda this but relies on the firmware doing it right which is not a given.
I think the reason to destroy the laptops was probably mainly cost.
A) Recycle costs:
Money for one old laptop: $150
Time taken to remove SSD/RAM from one laptop: $100
Limited labour resources, so people are taken off support calls to remove the SSD/RAM: $1000s in broken SLAs etc. due to the time taken to work on 100s of old laptops a day or extra people employed.
Total cost: $1000s
B) Land fill costs:
Shred laptop and send to landfill: $10 per laptop.
Total cost: $10 per laptop.
C) If the laptops could we wiped with an automated script:
The ssds can already be wiped on busyness machines, they all ship with opal drives these days and memory gets wiped by the machine being off, if you want you can run memtest over it to overwrite it a bunch of times (and also find out if the memory is still good).
Anyone paranoid enough to think about data retention in ran likely will also not be satisfied with encrypted ram or ssds or built in secure erase functions so I am not sure how much sense that whole point makes.
Pretty sure the point of memory encryption is not about that but for protecting against cold/warm-boot attacks and and hypervisor escapes.
I don’t know why that company was so paranoid.
It was mainly commercially sensitive data that has strict rules about its public release set by the Security and Exchanges Commission (SEC).
I.e. The announcement of takeovers and such like that might have a significant affect on share price.
So yeah the chance is pretty close to 0 they would be satisfied by whatever encrypted memory tech even if it somehow reached the bureaucrats that that is a thing.
It used to be in older AGESA builds. Whether that was exposed to the user to use, depends on the board maker. Frameworks UEFI was basic and didn’t show it.