AMD TSME Sessizce Gitti: Ryzen'de Cold Boot Saldırı Yüzeyi

NixOS 26.05’e geçiş sonrası sistemimi audit ederken dmesg çıktıları arasında hiç görmek istemediğim bir şeyi fark ettim: AMD’nin TSME özelliğine dair tek bir satır log yok.

TSME Nedir ve Neden Önemli?

AMD TSME (Transparent Secure Memory Encryption), Zen 1 / ilk nesil EPYC ile birlikte tanıtılan ve tüm sistem RAM’ini donanım düzeyinde şifreleyen kritik bir özelliktir.

“Transparent” (şeffaf) olması, işletim sisteminin veya uygulamaların bu şifrelemeden haberdar olmasına gerek kalmadan çalışması anlamına gelir. CPU ve bellek kontrolcüsü arasındaki tüm veri trafiği otomatik olarak AES-128 ile şifrelenir.

Bu özellik aktif olduğunda; sistemdeki herhangi bir RAM modülü fiziksel olarak söküldüğünde veya klasik bir “cold boot” (soğuk önyükleme) saldırısı denendiğinde, saldırganın eline geçen şey şifreli anlamsız bir gürültüden ibarettir.

Sistemimde Durum Ne?

Kullandığım işlemci bir Ryzen 5 7500F, yani Zen 4 mimarisi. Donanım seviyesinde bu destek var. Ancak kontrol ettiğimde:

sudo dmesg | rg -i "sme|tsme|encrypt"
# Çıktı: (boş)

grep -i "sme" /proc/cpuinfo
# Çıktı: (boş)

Eğer özellik aktif olsaydı kernel loglarında şunu görmem gerekirdi: x86/mm: AMD Memory Encryption enabled

Ama hiçbir şey yok. Kernel, TSME’yi görmüyor çünkü firmware düzeyinde (BIOS/UEFI) devre dışı bırakılmış. İşin asıl can sıkıcı yanı: EPYC ve Threadripper serilerinde açık gelen bu güvenlik özelliği, consumer (son kullanıcı) düzeyindeki AM5 anakartlarında sessizce kapatılmış. Üstelik herhangi bir resmi duyuru, release note veya BIOS changelog girişi bile yapılmadan.

dmesg üzerinden grafik birimindeki bellek şifrelemesini kontrol ettiğimde de tablo değişmiyor:

amdgpu: Trusted Memory Zone (TMZ) feature not supported
amdgpu: MEM ECC is not presented.
amdgpu: SRAM ECC is not presented.

Kısacası, consumer-tier donanımlarda güvenlik özellikleri sistematik bir şekilde budanmış durumda.

Tehdit Modeli: Cold Boot Saldırısı

DRAM (Dinamik RAM) modülleri, sistemin gücü kesildikten sonra bile saniyeler, hatta sıcaklığa bağlı olarak dakikalarca veriyi koruyabilir.

Bu süre, cihaza fiziksel erişimi olan yetenekli bir saldırganın belleği aniden dondurarak (örneğin sıkıştırılmış hava veya sıvı azot ile) RAM’i söküp başka bir sisteme takmasına ve içeriğini dump etmesine yeterlidir. TSME aktif olsaydı okunan şey sadece şifreli bir çöp olacaktı. Ama artık değil.

Bunun çok daha pratik ve yaygın olan bir vektörü var: Hibernate (Uyku Modu). Sistem hibernate olduğunda RAM içeriği (içindeki şifreler, SSH key’ler dahil) olduğu gibi diske yazılır. TSME ve ek korumalarınız yoksa, bu RAM dökümü disk üzerinde şifresiz şekilde hedefte bekler.

NixOS Mitigasyonu

TSME’yi doğrudan firmware düzeyinde açamayız — bu tamamen anakart üreticisinin (BIOS) inisiyatifinde ve ne yazık ki consumer board’larda bu seçeneği bize sunmuyorlar.

Ancak NixOS konfigürasyonumuz üzerinden alabileceğimiz sağlam tedbirler var:

1. Hibernation’ı Tamamen Devre Dışı Bırakmak

RAM dökümünün diskte savunmasız kalmasını engellemenin en kesin yolu:

boot.kernelParams = [ "nohibernate" ];

Bu kernel parametresi, sistemin RAM içeriğini diske yazmasını kökten engeller. 26.05 geçişimde bu ayar sistemimden düşmüştü (kaybolmuştu), audit sonrası bu yazıyı yayınlamadan önce config’e tekrar işledim.

2. Şifreli Swap Kullanımı

Eğer sisteminizde swap alanı (takas alanı) kullanıyorsanız, buraya da bellekten veriler sızabilir. Swap alanının şifreli olması bir lüks değil, zorunluluktur:

swapDevices = [{
  device = "/dev/disk/by-label/SWAP";
  randomEncryption.enable = true;
}];

3. Fiziksel Güvenlik ve Tam Disk Şifrelemesi (FDE)

Yazılım tarafındaki hiçbir önlem tam anlamıyla fiziksel güvenliğin yerini tutamaz. LUKS ile tam disk şifrelemesi (Full Disk Encryption) ve güvenli bir önyükleme (Secure Boot + TPM) bu tarz senaryolarda hayat kurtarır. Yazılımsal önlemler tamamlayıcıdır, ikame değildir.

Sonuç

Donanımın kapasitesinde olan, tasarımsal olarak var olan kritik bir güvenlik özelliği, pazar segmentasyonu (consumer vs enterprise) uğruna firmware tarafından sessizce kaldırılmış. Kullanıcı tarafında bununla ilgili bir bilgilendirme bile yok.

Bu durumu bir AMD hatası (bug) olarak değil, bir iletişim başarısızlığı olarak görüyorum — ama günün sonunda sonuç değişmiyor: Sistemin saldırı yüzeyi beklediğimden çok daha geniş.

nohibernate parametresi bu sistemde artık bir tercih değil, minimum gerekliliktir. TSME’nin son kullanıcı anakartlarına bir gün geri geleceğini bekleyerek sistem güvenliği planlanmaz.

Güvenlik Notu: Kendi Linux sisteminizi denetlemek için ara ara dmesg kayıtlarınızı okuyun. Bazen eksik olan satırlar, orada olanlardan çok daha fazlasını anlatır.

EOF.