# BIOS feature request: AMD Memory Guard (TSME) **URL:** \ **Category:** Framework Desktop\ **Tags:** bios\ **Created:** [June 1, 2026, 1:05am UTC](https://community.frame.work/t/bios-feature-request-amd-memory-guard-tsme/82831 "2026-06-01T01:05:38Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![Guest649](https://avatars.discourse-cdn.com/v4/letter/g/c57346/32.png) [@Guest649](https://community.frame.work/u/Guest649)\ **Post date:** [June 1, 2026, 1:05am UTC](https://community.frame.work/t/bios-feature-request-amd-memory-guard-tsme/82831/1 "2026-06-01T01:05:38Z")
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** : ```auto $ 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** : 1. Expose a TSME on/off toggle in the BIOS setup menu (default-on with no UI toggle would also be fine). 2. 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](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](https://winraid.level1techs.com/t/request-unlock-bios-uefi-for-amd-395-strix-halo/111395) ---
**Author:** ![Djip](https://avatars.discourse-cdn.com/v4/letter/d/82dd89/32.png) [@Djip](https://community.frame.work/u/Djip)\ **Post date:** [June 1, 2026, 10:40pm UTC](https://community.frame.work/t/bios-feature-request-amd-memory-guard-tsme/82831/2 "2026-06-01T22:40:37Z")
> [@Guest649](#): > > 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. I think only the PRO have it. It is not the one that is use on Framework Desktop… ---
**Author:** ![aLostEngineer](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/alostengineer/32/17759_2.png) [@aLostEngineer](https://community.frame.work/u/aLostEngineer)\ **Post date:** [June 9, 2026, 11:50pm UTC](https://community.frame.work/t/bios-feature-request-amd-memory-guard-tsme/82831/3 "2026-06-09T23:50:35Z")
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. 395 datasheet: [AMD Ryzen™ AI Max+ 395](https://www.amd.com/en/products/processors/laptop/ryzen/ai-300-series/amd-ryzen-ai-max-plus-395.html) 395 PRO datasheet (note all the added security features): [AMD Ryzen™ AI Max+ PRO 395](https://www.amd.com/en/products/processors/laptop/ryzen-pro/ai-max-pro-300-series/amd-ryzen-ai-max-plus-pro-395.html) ---
**Author:** ![Sergio\_Ortega](https://avatars.discourse-cdn.com/v4/letter/s/a3d4f5/32.png) [@Sergio\_Ortega](https://community.frame.work/u/Sergio_Ortega)\ **Post date:** [June 10, 2026, 7:59pm UTC](https://community.frame.work/t/bios-feature-request-amd-memory-guard-tsme/82831/4 "2026-06-10T19:59:12Z")
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. ---
**Author:** ![James3](https://avatars.discourse-cdn.com/v4/letter/j/b5e925/32.png) [@James3](https://community.frame.work/u/James3)\ **Post date:** [June 18, 2026, 8:37am UTC](https://community.frame.work/t/bios-feature-request-amd-memory-guard-tsme/82831/5 "2026-06-18T08:37:11Z")
Maybe this explains the situation a bit better: > [@Transparent Secure Memory Encryption (TSME) being removed by AGESA update](https://community.frame.work/t/transparent-secure-memory-encryption-tsme-being-removed-by-agesa-update/83101): > > Hi, I have just seen this: So, upgrading to the latest AMD AGESA might not be as tempting as before. ---
**Author:** ![Tactical.Finesse](https://avatars.discourse-cdn.com/v4/letter/t/977dab/32.png) [@Tactical.Finesse](https://community.frame.work/u/Tactical.Finesse)\ **Post date:** [June 18, 2026, 10:17am UTC](https://community.frame.work/t/bios-feature-request-amd-memory-guard-tsme/82831/6 "2026-06-18T10:17:35Z")
ARS had a story about this a few days ago. It appears to be deliberate after sale feature stratification > **[Users cry foul after AMD stripped memory crypto from its consumer CPUs](https://arstechnica.com/security/2026/06/users-cry-foul-after-amd-stripped-memory-crypto-from-its-consumer-cpus/)** > > AMD's stripping of TSME from consumer CPUs appears to be a deliberate, covert move. ---
**Author:** ![James3](https://avatars.discourse-cdn.com/v4/letter/j/b5e925/32.png) [@James3](https://community.frame.work/u/James3)\ **Post date:** [June 18, 2026, 11:05am UTC](https://community.frame.work/t/bios-feature-request-amd-memory-guard-tsme/82831/7 "2026-06-18T11:05:15Z")
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: 1. It takes too long (labour expense) to remove the SSD. 2. 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. ---
**Author:** ![Adrian\_Joachim](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/adrian_joachim/32/9949_2.png) [@Adrian\_Joachim](https://community.frame.work/u/Adrian_Joachim)\ **Post date:** [June 18, 2026, 11:47am UTC](https://community.frame.work/t/bios-feature-request-amd-memory-guard-tsme/82831/8 "2026-06-18T11:47:56Z")
> [@James3](#): > > 1. It takes too long (labour expense) to remove the RAM. > This ensures no company private data leaks. 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. ---
**Author:** ![dimitris](https://avatars.discourse-cdn.com/v4/letter/d/db5fbb/32.png) [@dimitris](https://community.frame.work/u/dimitris)\ **Post date:** [June 18, 2026, 6:38pm UTC](https://community.frame.work/t/bios-feature-request-amd-memory-guard-tsme/82831/9 "2026-06-18T18:38:55Z")
> [@James3](#): > > 1. It takes too long (labour expense) to remove the SSD. Would a `dd if=/dev/urandom of=/dev/nvme0n1 bs=1M count=`, 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. ---
**Author:** ![Adrian\_Joachim](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/adrian_joachim/32/9949_2.png) [@Adrian\_Joachim](https://community.frame.work/u/Adrian_Joachim)\ **Post date:** [June 19, 2026, 10:11am UTC](https://community.frame.work/t/bios-feature-request-amd-memory-guard-tsme/82831/10 "2026-06-19T10:11:14Z")
> [@dimitris](#): > > Would a `dd if=/dev/urandom of=/dev/nvme0n1 bs=1M count=`, 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? 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. > [@dimitris](#): > > 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? 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. ---
**Author:** ![James3](https://avatars.discourse-cdn.com/v4/letter/j/b5e925/32.png) [@James3](https://community.frame.work/u/James3)\ **Post date:** [June 19, 2026, 10:47am UTC](https://community.frame.work/t/bios-feature-request-amd-memory-guard-tsme/82831/11 "2026-06-19T10:47:16Z")
I think the reason to destroy the laptops was probably mainly cost. A) Recycle costs: 1. Money for one old laptop: $150 2. Time taken to remove SSD/RAM from one laptop: $100 3. 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: 1. 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: 1. Cost to start script: $10 2. Sell old latop: $150 Total profit: $140 Removal of TSME ensures a business decision of B. ---
**Author:** ![Adrian\_Joachim](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/adrian_joachim/32/9949_2.png) [@Adrian\_Joachim](https://community.frame.work/u/Adrian_Joachim)\ **Post date:** [June 19, 2026, 11:01am UTC](https://community.frame.work/t/bios-feature-request-amd-memory-guard-tsme/82831/12 "2026-06-19T11:01:33Z")
> [@James3](#): > > If the laptops could we wiped with an automated script: > > 1. Cost to start script: $10 > 2. Sell old latop: $150 > Total profit: $140 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. ---
**Author:** ![James3](https://avatars.discourse-cdn.com/v4/letter/j/b5e925/32.png) [@James3](https://community.frame.work/u/James3)\ **Post date:** [June 19, 2026, 11:11am UTC](https://community.frame.work/t/bios-feature-request-amd-memory-guard-tsme/82831/13 "2026-06-19T11:11:15Z")
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. ---
**Author:** ![Adrian\_Joachim](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/adrian_joachim/32/9949_2.png) [@Adrian\_Joachim](https://community.frame.work/u/Adrian_Joachim)\ **Post date:** [June 19, 2026, 11:31am UTC](https://community.frame.work/t/bios-feature-request-amd-memory-guard-tsme/82831/14 "2026-06-19T11:31:57Z")
> [@James3](#): > > It was mainly commercially sensitive data that has strict rules about its public release set by the Security and Exchanges Commission (SEC). 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. ---
**Author:** ![Guest649](https://avatars.discourse-cdn.com/v4/letter/g/c57346/32.png) [@Guest649](https://community.frame.work/u/Guest649)\ **Post date:** [June 20, 2026, 4:03pm UTC](https://community.frame.work/t/bios-feature-request-amd-memory-guard-tsme/82831/15 "2026-06-20T16:03:48Z")
crazy so it was available before? ---
**Author:** ![Tactical.Finesse](https://avatars.discourse-cdn.com/v4/letter/t/977dab/32.png) [@Tactical.Finesse](https://community.frame.work/u/Tactical.Finesse)\ **Post date:** [June 20, 2026, 5:18pm UTC](https://community.frame.work/t/bios-feature-request-amd-memory-guard-tsme/82831/16 "2026-06-20T17:18:04Z")
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. ---
**Author:** ![Tactical.Finesse](https://avatars.discourse-cdn.com/v4/letter/t/977dab/32.png) [@Tactical.Finesse](https://community.frame.work/u/Tactical.Finesse)\ **Post date:** [June 23, 2026, 2:54pm UTC](https://community.frame.work/t/bios-feature-request-amd-memory-guard-tsme/82831/17 "2026-06-23T14:54:44Z")
Update. AMD claims to be reversing course on this. Presuming they follow through the ball would be in OEMs court to implement it again > **[Following user outcry, AMD reinstates memory encryption in consumer CPUs](https://arstechnica.com/security/2026/06/following-user-outcry-amd-reinstates-memory-encryption-in-consumer-cpus/)** > > Critics saw the move as an underhanded way to steer them toward more costly chips.