AMDがメディア向け声明で、一部の非PRO Ryzen 9000シリーズのデスクトップCPUについて、Memory Guardを有効にするBIOS項目を7月のBIOSリリースで復帰させる方針を示した。対象はPRO向け管理機能全体ではなく、Transparent Secure Memory Encryption、つまりTSMEとして知られるメモリ暗号化機能の設定項目である。今回の論点は、一般的なデスクトップ利用者がすぐ攻撃されるという話ではない。BIOS更新によって、以前は使えていたと見られるセキュリティ機能の入り口が、はっきりした説明なしに使えなくなった点にある。

TSMEは、DRAMに出入りするデータをメモリコントローラ側で暗号化する仕組みだ。AMDのMemory Guard資料では、システムメモリ内に残るログイン情報、暗号化ディスクの鍵、機密ファイルの断片などを、コールドブート攻撃やDRAMインターフェースの盗聴、メモリモジュールの取り外しといった物理攻撃から守るための技術として説明されている。暗号鍵はシステム起動ごとに生成され、CPUコア上のソフトウェアからは見えず、AMD Secure Processorが管理する。OSやアプリケーションの変更を必要としない点も、TSMEの扱いをややこしくしている。

AD

消えたのは性能機能ではなく、BIOSが握る暗号化の入り口だ

発端になった公開issueでは、Ryzen 7 9700XとMSI X870Eマザーボードの組み合わせで、BIOS上のTSME項目を有効にしてもLinux側の検査で有効化を確認できない、という報告が出ている。報告者の環境では、fwupdmgr securityのHost Security IDが以前はEncrypted RAMを「Encrypted」と扱っていたが、2026年4月5日に「Not supported」へ変わった。TSME状態を示すtsme_statusは0で、BIOS設定と実際の暗号化状態が一致していなかった。

この話が単純な「Linuxの表示不具合」で終わらないのは、AMD側のLinuxエンジニアがTSMEの確認方法を整理しているためだ。TSMEはOSがページ単位で制御するSMEとは異なり、SYS_CFG MSRのSMEEビットだけでは判断できない。公開issueでは、CCP PCIデバイスに紐づくtsme_statusを確認するよう案内されている。fwupdのpci-pspプラグインも同じ考え方を採っており、tsme_statusを読み、値が偽ならEncrypted RAMを「not encrypted」として扱う。

ここで問題になるのは、BIOSに項目が見えていても、AGESAやプラットフォーム初期化の内部判断で実際には有効化されない場合があることだ。報告者は、マザーボードベンダー側の検証として、非PROのRyzen 9 9800X3Dでは内部フラグが偽になり、PRO系CPUでは有効化されるという比較を示している。ただし、この比較はAMDが公開した根本原因ではない。確定しているのは、少なくとも一部の非PRO Ryzen 9000デスクトップ環境で、BIOS項目とTSMEの実状態がずれ、AMDが7月のBIOSで項目を戻すとしたことだ。

Memory GuardはPROの看板機能だが、TSMEの境界はもっと曖昧だった

AMDの公式資料では、Memory GuardはAMD PRO security technologyの一部として説明されている。資料には、一般的なビジネス向けノートPCとデスクトップ向けに、Ryzen PROおよびAthlon PROでフルシステムメモリ暗号化を提供するという脚注もある。AMDがPRO製品の管理・セキュリティ機能としてMemory Guardを売り込んできたこと自体は、公開資料からも読み取れる。

一方で、TSMEはOSから見れば透過的なファームウェア管理の暗号化であり、SMEやSEVのようなOS・仮想化向け機能とは確認経路が異なる。公開issueのやり取りでも、SMEが有効か、TSMEが有効か、Memory Guardという製品名がどの範囲を指すのかが何度も混線している。SMEはOSが扱うメモリ暗号化の仕組みで、TSMEはファームウェアが全DRAMを暗号化する仕組みである。この二つを同じものとして扱うと、/proc/cpuinfoのsmeフラグやカーネルログだけを見て誤った結論に進みやすい。

AMDのMemory Guard資料が説明する技術的な利点も、ここでは両刃になる。OSやアプリを変えずに使えるということは、ユーザーが日常的な管理画面で有効状態を確認しにくいことでもある。Linuxではfwupdやsysfsのような確認経路があるが、それでもBIOS項目、AGESAの内部判断、PSPが返す状態を突き合わせる必要がある。物理攻撃への対策としては狭い用途の機能でも、ユーザーが設定したセキュリティ項目が本当に効いているかを確認できないなら、信頼の問題は大きくなる。

AD

7月の復帰は評価できるが、説明不足は残る

AMDがメディア向け声明で7月のBIOSリリースによる復帰を示したことで、少なくとも「非PRO Ryzen 9000では今後も使えない」という見方は後退した。声明では、一定の非PRO Ryzen 9000シリーズのデスクトップCPUで、Memory Guardを有効にするBIOS項目が以前は存在し、最近の更新で削除されていたことも認められている。ユーザー側の誤認や表示上の混乱だけで片付く話ではなく、更新によって見える設定項目が変わったことをAMDが認めた形になる。

ただし、復帰予定は説明の代わりにはならない。なぜ削除されたのか、どのAGESA枝で起きたのか、どのCPUとマザーボードが影響を受けたのか、BIOS更新後にユーザーがどの方法で有効状態を検証すべきかは、まだ明確ではない。公開issueでも、古いBIOSへ戻すとTSMEが復帰したという報告がある一方、別のRyzen構成では新しいAGESAでもTSMEが有効だという報告がある。これを全Ryzen世代の問題として広げる根拠は弱い。

CPUのセキュリティ機能は、脆弱性修正やメモリ互換性改善と同じBIOS更新に含まれる。利用者は、更新すれば安全になるという前提でファームウェアを適用する。その更新で、物理攻撃対策の選択肢が説明なしに消えるなら、攻撃リスクそのものよりも、更新の意味を判断できなくなることが問題になる。特にAGESAは、CPU初期化、メモリ、I/O、セキュリティ機能の振る舞いを左右するが、一般ユーザーにとって変更内容はマザーボードベンダーの短いリリースノート越しにしか見えないことが多い。

次の焦点は「戻るか」ではなく「確認できるか」だ

7月のBIOSで見るべき点は、項目が戻ることだけではない。BIOSでMemory GuardまたはTSMEを有効にしたとき、tsme_statusやfwupdのEncrypted RAM判定が実際に変わるか。対象が非PRO Ryzen 9000のどこまでなのか。マザーボードベンダーごとの配信時期とAGESAバージョンがどう示されるのか。これらが見えなければ、復帰してもユーザーは「有効にしたつもり」の状態から抜け出せない。

AMDにとって、この問題はMemory GuardをPRO向け機能としてどう位置づけるかだけでは片付かない。PRO製品の差別化は企業向け機能として理解できるが、非PRO環境でBIOS項目が見え、ユーザーが有効状態を確認していた機能を、更新で黙って外すと受け取られれば、AGESA更新全体への信頼を削る。7月のBIOSは、TSMEという限定的な機能を戻すだけでなく、セキュリティ機能の変更をどこまで説明するのかを測る場になる。