Az AMD processzorok biztonsági funkciói az elmúlt évtizedben látványos fejlődésen mentek keresztül: a virtualizációs kiterjesztésektől kezdve a firmware-szintű védelmeken át egészen a memóriatitkosításig. Ebben a sorban különösen fontos szerepet játszik a Transparent Secure Memory Encryption (TSME), amely hardveresen, az operációs rendszertől függetlenül képes a teljes rendszermemória titkosítására. A közelmúltban azonban kiderült, hogy az AMD csendben, dokumentálatlanul eltávolította ezt a funkciót a consumer Ryzen CPU-król – miközben a vállalati, PRO és EPYC vonalon továbbra is elérhető.

Ez a lépés nemcsak biztonságtechnikai, hanem bizalomtechnikai kérdéseket is felvet, különösen a Linuxot használó, adatvédelemre érzékeny felhasználók körében. A történet egy Linuxos hobbista, Ben Kilpatrick hónapokig tartó nyomozásán keresztül rajzolódik ki, és jól megmutatja, hogyan kapcsolódik össze a firmware (AGESA), a BIOS-beállítások, a CPU-szintű képességek és az operációs rendszer biztonsági auditja.

Mi az a TSME, és miben különbözik az SME-től?

Az AMD memóriatitkosítási technológiái közül két kulcsfogalommal érdemes kezdeni:

• SME (Secure Memory Encryption): operációs rendszer által vezérelt funkció, amely egyetlen hardverkulccsal titkosítja a memóriát, de lap-szinten (page-level) szabályozható, hogy mely memórialapok legyenek titkosítva. A kernel (például Linux) explicit módon jelöli, mely lapokra vonatkozzon a titkosítás. Az AMD dokumentációja szerint az SME hivatalosan a PRO és EPYC szegmenshez kötött, és nem része a consumer Ryzen marketingelt funkciókészletének.
• TSME (Transparent Secure Memory Encryption): firmware által vezérelt, „átlátszó” titkosítás, amely az összes RAM-ot titkosítja, az operációs rendszer tudatos közreműködése nélkül. A BIOS-ban engedélyezhető, és ha aktív, a CPU memóriavezérlője minden írást titkosít, minden olvasást visszafejt. A rendszer és az alkalmazások ebből semmit nem érzékelnek, a titkosítás teljesen transzparens.

Mindkét technológia célja, hogy megnehezítse vagy ellehetetlenítse a fizikai támadásokat, például:

• cold boot attack: a gép hirtelen újraindítása vagy áramtalanítás után a DRAM tartalmának kiolvasása, amíg a cellákban még megmarad a töltés;
• DRAM bus snooping: a memória és a CPU közötti adatvonalak lehallgatása speciális hardverrel;
• memóriamodulok eltávolítása, más rendszerben történő kiolvasása.

A TSME ebből a szempontból különösen vonzó: nincs szükség OS-támogatásra, nincs API, nincs konfigurációs bonyodalom – ha a BIOS-ban engedélyezve van, a teljes RAM titkosított. Ezért vált sok, adatvédelemre érzékeny felhasználó számára „alapértelmezett elvárássá”, különösen Linux alatt, ahol a hardveres biztonsági funkciók kihasználása gyakran tudatos döntés eredménye.

Hogyan került TSME a consumer Ryzen CPU-kba?

Az AMD eredeti kommunikációja alapján a TSME-t elsősorban a vállalati és szerver szegmenshez kötötte, de a gyakorlatban a funkció éveken át működött számos consumer Ryzen modellen is. Erre utalnak többek között az AMD mérnökeinek nyilvános megjegyzései:

• 2020-ban Tom Lendacky, az AMD egyik vezető szoftvermérnöke egy nyilvános fejlesztői threadben azt írta, hogy a Ryzen 3700X (egy tipikus consumer CPU) „should support TSME”.
• 2025-ben ugyanebben a threadben azt javasolta, hogy ha elérhető, érdemes a TSME-t használni, de ez egy BIOS-opció, amelyet az alaplapgyártónak kell kitenni.

Ez a gyakorlatban azt jelentette, hogy sok felhasználó – köztük Linuxot futtatók – a BIOS-ban engedélyezhette a TSME-t, és a rendszerük ténylegesen titkosított memóriával futott, még akkor is, ha a marketinganyagok ezt nem hangsúlyozták. A funkció meglétét különféle eszközökkel lehetett ellenőrizni, például a Linux alatt futó Host Security ID (HSI) auditálási funkcióval, amely a firmware- és hardverbiztonsági konfigurációkat értékeli.

AGESA, BIOS és a rejtett kapcsoló: hol tűnt el a TSME?

A történet fordulópontja az AMD AGESA (AMD Generic Encapsulated Software Architecture) komponenséhez kapcsolódik. Az AGESA egy firmware-keretrendszer, amely a CPU inicializálását, a memóriatréninget, a platform-szintű hardverkonfigurációt végzi még azelőtt, hogy az operációs rendszer betöltődne. Az alaplapgyártók BIOS-frissítései tipikusan új AGESA-verziókat is tartalmaznak.

Ben Kilpatrick egy Ryzen 7 9700X (Zen 5) processzorral szerelt gépen új Linuxot telepített, és a szokásos módon lefuttatta a HSI-t, hogy ellenőrizze a biztonsági funkciók állapotát. A kimenetben azonban a következő sor fogadta:

„encrypted RAM: not supported”

Korábbi mentései alapján tudta, hogy ugyanezen a rendszeren korábban a TSME „encrypted” státuszt mutatott. A BIOS-ban a TSME opció továbbra is engedélyezve volt, ezért a változás első ránézésre megmagyarázhatatlannak tűnt. Innen indult a hónapokig tartó vizsgálat.

Az MSI (az alaplap gyártója) támogatásával és mérnökeinek bevonásával Kilpatrick összehasonlító teszteket végeztetett:

• Régebbi AGESA-verzióval a consumer Ryzen CPU-kon a TSME aktív volt.
• Újabb, konkrétan az AGESA 1.2.7.0 verziótól kezdve a TSME státusz „not supported”-re váltott ugyanazon a hardveren.
• Ugyanakkor a PRO Ryzen CPU-k esetén, ugyanazon alaplapokon és BIOS-verziókkal, a TSME továbbra is működött.

Ez erősen arra utalt, hogy nem a szilícium változott, hanem a firmware-ben (AGESA) történt olyan módosítás, amely policy-szinten letiltja a TSME-t a consumer SKU-kon.

ABL, DfIsTsmeEnabled és a belső flag-ek

Az MSI mérnökei mélyebbre ástak, és memóriadumpokat készítettek az AMD Boot Loader (ABL) futása közben. Az ABL az AGESA egyik komponense, amely a hardver inicializálásának kritikus szakaszait végzi. Itt találták meg a kulcsot jelentő belső jelzőt:

• DfIsTsmeEnabled: egy AGESA-szintű flag, amely azt jelzi, hogy a TSME engedélyezve van-e a firmware-inicializáció során.

A memóriadumpok összehasonlítása során a következő mintázat rajzolódott ki:

• Consumer Ryzen (pl. 9800X3D): a DfIsTsmeEnabled flag FALSE értéket vett fel, függetlenül attól, hogy a BIOS-ban a TSME „AUTO” vagy „ENABLED” állásban volt.
• PRO Ryzen (pl. 9945): ugyanazon alaplapon és BIOS-verzióval a flag TRUE lett, ha a TSME-t a BIOS-ban ENABLED-re állították.

Ez egyértelműen azt mutatta, hogy a TSME státuszát AGESA-szinten határozzák meg, és a consumer SKU-k esetében a firmware tudatosan állítja a flaget FALSE-ra, még akkor is, ha a felhasználó a BIOS-ban engedélyezi a funkciót. A BIOS-felület tehát látszólag kínál egy opciót, amely a háttérben nem tud érvényre jutni a firmware policy miatt.

MSI, Gigabyte, Asus: platformfüggetlen viselkedés

Az MSI nem állt meg a saját lapjainál: a vizsgálat során Gigabyte alaplapokon is reprodukálták a jelenséget. A consumer Ryzen CPU-k régebbi AGESA-val TSME-t támogattak, az újabb AGESA 1.2.7.0-tól kezdve viszont „not supported” státuszt mutattak. A PRO CPU-k mindkét esetben működő TSME-t produkáltak.

Az MSI termékmarketing-csapata Kilpatrick beszámolója szerint azt közölte vele, hogy az AMD hivatalosan kommunikálta feléjük: a TSME kizárólag PRO sorozatú processzorokon támogatott. Ezt a gyakorlatban egy Asus X870E alaplapon is igazolták, ahol egy Ryzen 9800X3D (consumer) és egy Ryzen 9945 PRO összehasonlítása során a TSME státusz a PRO CPU-n 1 (engedélyezve), a consumer CPU-n 0 (letiltva) értéket mutatott, azonos BIOS és beállítások mellett.

Mindez arra utal, hogy a TSME-vel kapcsolatos változás platformfüggetlen, és SKU-szintű döntés eredménye: a PRO és EPYC vonalon engedélyezett, a consumer Ryzen szegmensben pedig AGESA-szinten letiltott funkcióról van szó.

AMD válaszai: „PRO only”, de magyarázat nélkül

Kilpatrick a vizsgálat során nyilvános bugreportot nyitott az AMD publikus GitHub-repozitóriumában, ahol két AMD-mérnök is reagált:

• Tom Lendacky kezdetben nem tudta megmondani, mi okozza a változást, és a BIOS-opció ki- és bekapcsolását javasolta, illetve az alaplapgyártó felé irányította a hibajelentést.
• Mario Limonciello, az fwupd-ben található HSI-funkció karbantartója, szintén a BIOS-beállítások ellenőrzését javasolta, majd az alaplapgyártó bevonását.

Miután Kilpatrick visszatért az MSI által szolgáltatott részletes eredményekkel – beleértve az ABL-dumpokat és a DfIsTsmeEnabled flag viselkedését –, egyértelműen rákérdezett: a consumer SKU-kon a FALSE-ra állított flag szilícium-szintű korlátozás, vagy firmware policy eredménye? A válasz lényegében az volt, hogy „nincs több megosztható információ”.

Az AMD hivatalos, e-mailben adott nyilatkozata annyit mondott ki, hogy a TSME „csak PRO CPU-kon alkalmazott biztonsági funkció az AMD PRO Technologies részeként”. Ez az első ismert alkalom, hogy a gyártó explicit módon kimondta a TSME PRO-exkluzivitását. Arra azonban nem adott magyarázatot, hogy:

• miért működött éveken át consumer Ryzen CPU-kon is,
• miért és mikor döntöttek úgy, hogy AGESA-szinten letiltják,
• miért nem tájékoztatták erről egyértelműen a felhasználókat és partnereket.

Biztonsági és bizalmi következmények Linux-felhasználók számára

Linux alatt a hardveres biztonsági funkciók kihasználása gyakran tudatos döntés: a felhasználók BIOS-beállításokat módosítanak, kernelparamétereket adnak meg, audit-eszközöket futtatnak. A TSME különösen vonzó volt azok számára, akik:

• fizikai hozzáféréssel fenyegetett környezetben üzemeltetnek gépeket (irodák, co-location, otthoni NAS-ok),
• titkosított lemezek mellett a RAM-tartalom védelmét is fontosnak tartják,
• minimalizálni akarják a konfigurációs komplexitást (TSME: „bekapcsolod a BIOS-ban, és kész”).

Az, hogy a TSME csendben eltűnt a consumer Ryzen CPU-król, több szinten is problémás:

• Biztonsági szint: azok a felhasználók, akik korábban TSME-re támaszkodtak, most védelem nélkül maradhatnak a fizikai memóriatámadásokkal szemben, ha nem ellenőrzik aktívan a funkció státuszát.
• Átláthatóság: a BIOS továbbra is kínálhat TSME-opciót, amely a háttérben hatástalan, mert az AGESA SKU-szinten letiltja. Ez félrevezető konfigurációs élmény.
• Bizalom: a felhasználók és fejlesztők éveken át AMD-mérnökök nyilvános kommentjeire és a tényleges működésre alapozva tekintették a TSME-t a consumer Ryzen csomag részének. A funkció csendes visszavonása sokak számára „árulásként” hat.

Joe FitzPatrick, szilíciumszintű biztonsági szakértő szerint legalább egy őszinte magyarázat indokolt lenne, még akkor is, ha az így hangzana: „a TSME-t sosem szántuk consumer CPU-kra, véletlenül engedélyeztük néhány firmware-ben, de nem tudjuk garantálni a helyes működését, ezért letiltottuk”. Jelenleg azonban ilyen részletező magyarázat nem ismert.

Gyakorlati tanácsok Linux Mint és más Linux rendszerek felhasználóinak

Akik Linuxot – így például Linux Mintet – futtatnak AMD Ryzen processzoron, és fontos számukra a memóriatitkosítás, érdemes néhány gyakorlati lépést megfontolni:

• TSME státusz ellenőrzése: Linux alatt a fwupd által biztosított HSI (Host Security ID) vagy más audit-eszközök segítségével ellenőrizhető, hogy a rendszer „encrypted RAM”-ként látja-e a memóriát. Ha „not supported” jelenik meg, a TSME gyakorlatilag nincs jelen.
• BIOS-beállítások felülvizsgálata: még ha a BIOS kínál is TSME-opciót, nem garantált, hogy az AGESA valóban engedélyezi. A státuszt mindig OS-ből is érdemes ellenőrizni.
• Alternatívák mérlegelése: ha a TSME nem elérhető, marad a lemezszintű titkosítás (LUKS, dm-crypt), illetve virtualizációs környezetben az olyan technológiák, mint az SEV/SEV-ES/SEV-SNP (ahol támogatott), amelyek a vendég VM-ek memóriáját védik.
• Hardverválasztás: akik számára kritikus a hardveres memóriatitkosítás, azoknak érdemes lehet PRO vagy EPYC platformot választani, ahol az AMD hivatalosan is vállalja a TSME/SME támogatását.

Összehasonlítás: AMD TSME vs. más gyártók megoldásai

A memóriatitkosítás nem AMD-exkluzív koncepció, de a megvalósítás gyártónként eltér. Az AMD TSME-je abban erős, hogy teljesen transzparens és firmware-vezérelt, így minimális OS-integrációt igényel. Más gyártók megoldásai gyakran szorosabban integrálódnak a platform biztonsági architektúrájába (például firmware, TPM, secure boot lánc), és eltérő konfigurációs modelleket használnak.

Linux szempontból az AMD TSME egyik nagy előnye éppen az volt, hogy a kernelnek és a disztribúciónak nem kellett külön támogatást implementálnia a használatához: a titkosítás a hardver és a firmware szintjén történt. Ezért is érinti érzékenyen a közösséget, hogy a funkció a consumer szegmensben eltűnt.

Lehetséges motivációk és jövőbeli kilátások

Az AMD nem részletezte, miért döntött úgy, hogy a TSME-t a PRO és EPYC szegmensre korlátozza. Néhány lehetséges – de nyilvánosan nem megerősített – szempont, amely ilyen döntések mögött általában felmerülhet:

• Termékpozicionálás: a vállalati és szerver CPU-k egyik fontos értékajánlata a kiterjesztett biztonsági funkciókészlet. A TSME ilyen értelemben „prémium” funkciónak tekinthető, amelyet a gyártó a magasabb árú SKU-khoz köt.
• Támogatási és validációs költségek: a memóriatitkosítás teljes platformszintű validációja (különböző alaplapok, RAM-konfigurációk, OS-ek) jelentős erőforrást igényel. Lehetséges, hogy az AMD ezt a terhet a vállalati szegmensre kívánja koncentrálni.
• Kompatibilitási megfontolások: bizonyos perifériák, diagnosztikai eszközök vagy speciális felhasználási módok érzékenyek lehetnek a transzparens memóriatitkosításra. Ha a consumer piacon több inkompatibilitási probléma merült fel, az is motiválhatta a funkció visszavonását.

Mindezek azonban jelenleg csak általános iparági megfontolások, nem konkrét AMD-nyilatkozatok. A jövő szempontjából kulcskérdés, hogy az AMD:

• egyértelmű, részletes kommunikációt ad-e a TSME státuszáról a különböző SKU-kon,
• biztosít-e stabil, hosszú távú garanciát a PRO/EPYC vonalon a memóriatitkosítási funkciókra,
• és hogy a Linux-közösség mennyire tud ezekre a funkciókra megbízhatóan építeni a jövőbeni biztonsági architektúrák tervezésekor.

Az eset mindenesetre jól rávilágít arra, hogy a modern CPU-k biztonsági funkciói nem pusztán technikai kérdések: a firmware-policy, a termékpozicionálás és a gyártói kommunikáció legalább annyira meghatározza, hogy a felhasználók végül milyen védelmet kapnak – vagy éppen veszítenek el – a gépükben lapuló szilíciumtól.