Reptar: Intel CPU’nun FSRM/REX açığı
(lock.cmpxchg8b.com)- Bazı Intel işlemcilerde
rep movsile yinelenenrex.röneki FSRM optimizasyonu ile birleştiğinde CPU, normal kuralların dışına çıkan bir “glitch” durumuna girebilir - Nedeni, x86’nın gevşek önek çözümlemesi ve
movsbgibi örtük operand kullanan komutlarda normalde anlamsız olması gerekenrexönekinin belirli bir optimizasyon yoluna girmesidir - Google’ın doğrulama hattı, Ağustos 2023’te bu kombinasyonda öngörülemez sonuçlar buldu; beklenmeyen dallanmalar, koşulsuz dallanmaların yok sayılması,
xsavevecallkomutlarında komut işaretçisinin kaydedilmesinde anomaliler gözlemledi - Birden fazla çekirdek aynı hatayı aynı anda tetiklerse machine check exception ve sistemin durması meydana gelebilir; yetkisiz bir konuk VM içinde de yeniden üretilebildiği için bulut ortamları açısından önemlidir
- Intel, etkilenen işlemciler için mikrokod güncellemesi yayımladı; güncellemenin mümkün olmadığı durumlarda
IA32_MISC_ENABLEüzerinden fast strings kapatılabilir, ancak bu büyük performans kaybına yol açar
x86 önekleri ve rep movsb
rep movsb, x86’da belleği taşımak için kullanılan yerleşik bir yöntemdir; kaynak, hedef, yön ve sayaç ayarlandığında işlemci tekrarlı kopyalamayı yürütür- Asıl komut
movsb’dir;repise bu komutun birden çok kez tekrarlanmasını sağlayan bir **önek (prefix)**tir - x86 komut çözümlemesi görece gevşektir; anlamsız veya çakışan önekler eklense bile genellikle yok sayılır
- Derleyiciler, tek bir komutu istenen hizalama sınırına kadar doldurmak için bu tür yinelenen önekleri kullanabilir
rex,vex,evex, sonraki komutun çözümleme biçimini değiştiren öneklerdir
rex önekinin sorun yarattığı kombinasyon
- i386’te genel amaçlı 8 register olduğu için register’lar 3 bit ile belirtilebiliyordu; ancak x86-64’te 16 genel amaçlı register olduğundan ek bitler gerekir
rexöneki, sonraki komut operandları kodlarken ödünç alabileceği ek bitler sağlar- Genellikle
rex.rxbşeklinde gösterilir;b,x,r,wbitleri isteğe bağlı olarak ayarlanır
- Genellikle
movsb’de operandlar komutta açıkça belirtilmez, hepsi örtüktür; bu yüzdenrex.rxb rep movsbiçindekirexbitlerinin anlamsız olması gerekir- Normalde işlemci bu tür
rexöneklerini sessizce yok sayar, ancak fast short repeat move destekleyen sistemlerde bu kombinasyon bir güvenlik açığına dönüşür
FSRM ve etkilenen işlemciler
- FSRM, Ice Lake ile tanıtılan ve ERMS’in kısa dize işleme sınırını tamamlayan bir özelliktir
- ERMS (enhanced repeat move/store), tampon hizalamayı ve geniş yazmaları mikrokod içinde işleyerek mevcut
rep movsbkodunu daha hızlı hâle getirebilir- İlk kurulum maliyeti yüksek olduğundan çok kısa dizeler için uygun değildir
- FSRM, 128 bayt ve altındaki kısa taşımaları daha hızlı işlemek için tasarlanmış bir özelliktir
- Destek durumu,
/proc/cpuinfoiçindekiflagssatırındafsrmbayrağıyla kontrol edilebilir - FSRM içeren işlemci örnekleri şunlardır
- Ice Lake
- Rocket Lake
- Tiger Lake
- Raptor Lake
- Alder Lake
- Sapphire Rapids
- Bu liste kapsamlı değildir; tam liste için Intel advisory INTEL-SA-00950 kontrol edilmelidir
Keşif ve yeniden üretim
- Google’ın doğrulama hattı, Oracle Serialization tekniğiyle rastgele üretilmiş programların iki biçimini çalıştırıp nihai durumlarının aynı olup olmadığını karşılaştırır
- İlgili açıklama önceki yazı Oracle Serialization içinde yer alır
- Ağustos 2023’te, FSRM ile optimize edilmiş
rep movskomutuna yinelenenrex.röneki eklendiğinde öngörülemez sonuçlar ortaya çıktı - Gözlemlenen anormal davranışlar şunlardı
- Beklenmeyen konumlara dallanma
- Koşulsuz dallanmaların yok sayılması
xsaveveyacallkomutlarında komut işaretçisinin (instruction pointer) doğru kaydedilmemesi- Debugger’ın imkânsız durumlar raporlaması
- Birden fazla çekirdek aynı hatayı tetiklerse işlemci machine check exception raporlayıp durabilir
- Yetkisiz bir konuk VM içinde de yeniden üretilebildiğinden bulut sağlayıcıları için güvenlik açısından önemli bir sorun hâline gelir
- Yeniden üretim aracı ve araştırma materyalleri Google’ın security research repository deposunda yayımlandı
icebreakaracının yerel aynası da icebreak.tar.gz olarak sunulur
icebreak, farklı çekirdek çiftleri belirleyerek yeniden üretmeyi dener- Etkilenmeyen sistemlerde sonsuz döngü gibi hiç çıktı olmamalıdır
- Etkilenen sistemlerde her başarılı yeniden üretimde
.çıktısı verilir - SMT kardeş çekirdeklerde rastgele dallanma gözlemlenebilir
- Aynı paketteki SMP kardeş çekirdeklerde machine check gözlemlenebilir
- İki farklı çekirdek belirtilmezse hammer thread gerekebilir
Olası neden ve gözlemlenen etki
- Modern sistemlerde mikrokod davranışı herkese açık olmadığından, temel neden yalnızca gözleme dayalı bir teori olarak ele alınabilir
- CPU kabaca front-end ve back-end olarak ikiye ayrılır
- Front-end komutları getirir, çözümler ve μop’lar üretir
- Back-end komutları sıra dışı çalıştırır, sonuçları ROB’de (reorder buffer) saklar ve emekliye ayırır
- Bu hata, front-end’in
movsbkomutunun boyutunu yanlış hesaplamasına ve sonrasında ROB girdilerinin yanlış adreslerle ilişkilendiği bir duruma yol açıyor gibi görünür - Bu durumda komut işaretçisinin yanlış hesaplandığı bir karmaşa durumu ortaya çıkar
- Sistem sonunda kendi içinde tutarlı bir duruma geri dönebilir, ancak ara sonuçlar yanlış olabilir
- Birden fazla SMT veya SMP çekirdeği aynı anda bu duruma girerse, machine check’i zorlayacak kadar mikromimari durum bozulması meydana gelebilir
- Sistem durumu machine check oluşturacak kadar bozulabilir ve SMT kardeş çekirdeğe zamanlanan süreçlerin çalışmasında thread’ler arası etkileşim gözlemlenir
- Bozulmanın yetki yükseltme için yeterince hassas biçimde kontrol edilip edilemeyeceği doğrulanmamıştır
Önlemler
- Intel, etkilenen tüm işlemciler için güncellenmiş mikrokodu INTEL-SA-00950 kapsamında yayımladı
- İşletim sistemi veya BIOS tedarikçisi güncellemeyi hâlihazırda sunmuş olabilir
- Güncelleme yapılamıyorsa
IA32_MISC_ENABLEmodele özgü register’ı üzerinden fast strings devre dışı bırakılabilir - Fast strings’i devre dışı bırakmak büyük performans kaybına neden olduğundan, kesinlikle gerekli olmadıkça kullanılmamalıdır
İlgili CPU hatası materyalleri
- Google, keşfettiği CPU hatalarını kamuya açıklıyor; bazıları güvenlik etkisi olmasa bile okunmaya değer
- Örnek materyaller
- movlps just doesn’t work:
movlps’in çalışmadığı bir örnek - registers can sometimes roll back: register’ların önceki değerlere geri dönebildiği bir örnek
- movlps just doesn’t work:
1 yorum
Hacker News görüşleri
İlgili yazı: https://cloud.google.com/blog/products/identity-security/goo...
https://news.ycombinator.com/item?id=38268043 adresinden gelen içerik; yorumlar buraya birleştirildi
Bu yazıyı okuyunca yazılımımın üzerinde çalıştığı donanım hakkında ne kadar az şey bildiğimi fark ettim
“Önekler (prefix), özellikleri açıp kapatarak komutların davranışını değiştirmeyi sağlar” deniyor; bir özelliği açıp kapatmak için neden “önek” gerektiğini merak ediyorum
BIOS’a girmeden özellikleri dinamik olarak değiştirmek için mi?
REP öneki en yaygın olanıdır; aynı komutun değişken sayıda tekrarlanmasını sağlar
Tekrar sayısı CX yazmacından alınır ve bellekten nesne taşımak gibi yaygın döngüleri çok kısa hâle getirir
memcpy işlevi çoğu zaman tek bir REP MOVS komutu olarak inline edilir; gerekirse sayacı CX’e kopyalayan bir komut da eklenir
REX öneki de 64 bit programlar 64 bit değerler ve adreslerle sık çalıştığı için oldukça yaygındır
Hiçbir önek BIOS vb. üzerinden genel olarak ayarlanabilen bir şeyi değiştirip açıp kapatmaz; hepsi yalnızca sıradaki komutun ne yapacağını belirtir
Nadiren kullanılan adresleme biçimlerinde DS yerine başka bir segment kullanılmasını sağlayan “segment öneki” bulunur; x86_64’teki “REX” öneki ise yazmaç alanlarına bit ekleyerek 16 genel amaçlı yazmacın kullanılabilmesini sağladı
Benzer şekilde “LOCK” öneki, özgün tanımı zayıf olsa da bazı bellek işlemlerini sistemin geri kalanına karşı atomik hâle getirir; örneğin “LOCK CMPXCHG” ile karşılaştır-ve-ata uygulanır
Diğer CPU mimarileri de bu tür işlemleri ifade eder, ancak genellikle bunları mevcut komut alanına yerleştirir; bu da tüm komutları ifade etmek için daha fazla bit gerektirir
Burada sorun olan “REP” öneki özellikle bir istisna sayılır; eski zamanlardan kalma bir mikrokod tekrar önekidir
Yine de memset/memmove gibi bugün de performans açısından kritik işlemleri temsil ettiği için CPU üreticilerinin bunları optimize etmeye devam etmesi değerli; bu hata da sanki o süreçte ortaya çıkmış gibi görünüyor
En büyük sorun, komut kodlama alanını “verimli kullanmış” olmasıydı
Daha sonra yeni komutlar, daha kötüsü ek yazmaçlar ortaya çıkınca yeni komut varyantlarının bir şekilde araya sıkıştırılması gerekti; bunun yolu da önekler eklemek oldu
Komut kümesi her genişletildiğinde opcode alanının bir kısmı oyulup içine yeni bir önek tıkıştırıldı
Intel’in bu yıl bir başka yeni yöntem önermesine bakılırsa bu gidişat sürecek gibi
Teşhis süreci, qemu’nun repz ret ile karşılaştığında olanları hatırlattı: https://repzret.org/p/repzret/
HN kurallarına göre böyle başlıkların yasaklanması gerektiğini düşünüyorum
Bağlantının ne olduğunu hiç söylemiyor; URL ise daha da kafa karıştırıcı
Başlık bu kadar anlamsızsa, paylaşan kişinin kısa bir açıklama eklemesi gerektiğini düşünüyorum
Başlığa mümkün olduğunca fazla bağlam konduğunda insanların bağlantıya tıklamadığını, yorumlarda da tweet’e tepki verir gibi yalnızca kendi ilgi alanlarını cilaladıklarını gördük
HN, entelektüel merakı ve bağlantıya tıklamayı teşvik eden bir orta yol seçiyor
Belirsiz bir başlık yüzünden bağlantıya tıklamayı reddetseniz bile en azından bağlantıya tıklayan kişilere yanıt vermiş oluyorsunuz; bence bu, internetin başka yerlerine göre daha iyi
Belirsiz ve esprili bir başlığı haklı çıkaracak kadar getirisi olmayan yazılar, bu yazının aksine ön sayfadan düşer
Yazı çok iyi yazılmış
Assembly programlama ve Intel komut kümesi bir yana, mikromimari hakkında da neredeyse hiçbir şey bilmiyorum; yine de anlatımı takip edebildim ve burada ne olduğunu kabaca anladığımı hissediyorum
AMD CPU’ların da etkilenip etkilenmediğini bilen var mı merak ediyorum
Sorun gerçekten işlemcinin komut uzunluğunu karıştırmasıysa, bunun büyük bir performans düşüşü olmadan mikrokodla düzeltilebilmesi etkileyici
Sezgim tamamen yanlış olabilir ama komut uzunluğu hesaplamasının doğrudan mantık kapılarıyla sentezlenen bir şey olacağını sanırdım
Yeniden düşününce, uOP çözücüsü donanımsal olarak gayet sağlam olabilir; mikrokodla optimize edilmiş kopyalama rutini ise uOP akışı hakkında doğru olmayan bir çıkarım yapmaya çalışıyor olabilir
Örneğin “ha, bu rep mov; döngü için iki uOP geriye gitsem yeter” gibi bir şey olabilir
Intel CPU ekibinin ayrıntıları açıklayacağını sanmıyorum
“ERMS” ve “FSRM”i pek bilmiyorum; Google’da da iyi kaynak neredeyse yok gibi görünüyor
Bunların, optimize edilmiş SSE
memcpyuygulaması yerinerep movsb’nin en yüksek performansla kullanılabileceğini bildiren CPUID bayraklarından ibaret olup olmadığını, yoksarep movsb’yi daha hızlı yapan özel bir kodlama ya da önek mi olduklarını merak ediyorumİkincisiyse neden gerekli olduklarını ve FSRM’nin nasıl kullanıldığını da bilmiyorum
ERMS, AVX’in daha ucuz bir alternatifiymiş; FSRM de kısa bloklar için daha iyi bir sürüm gibi görünüyor
“Daha sonraki işlemcilerin düşük maliyetli sürümleri olan, 2017’de çıkan Kaby Lake Celeron ve Pentium’larda hızlı bellek kopyalama için kullanılabilecek AVX yok, ama Enhanced REP MOVSB var
Ayrıca 2018’den sonra çıkan bazı Intel mobil ve düşük güç mimarileri SkyLake tabanlı olmasa da, önceki nesil mikro mimarilere kıyasla REP MOVSB ile CPU döngüsü başına yaklaşık iki kat daha fazla bayt kopyalıyor”
“Ice Lake mikro mimarisindeki Fast Short REP MOV’dan (FSRM) önce, Enhanced REP MOVSB (ERMSB) ancak blok boyutu en az 256 bayt olduğunda AVX kopyalama veya genel amaçlı kayıt kopyalamadan daha hızlıydı
64 bayttan küçük bloklarda ERMSB’nin iç başlangıç maliyeti yaklaşık 35 döngüyle yüksek olduğu için çok daha yavaştı; FSRM özelliğinin amacı 128 bayttan küçük blokları da hızlandırmaktı”
[1] https://stackoverflow.com/a/43837564
[2] http://www.intel.com/content/dam/www/public/us/en/documents/...
En iyi komut seçimi ve zamanlaması derleme zamanında statik olarak yapılabilir; ya da çalışma zamanında birden fazla kütüphane fonksiyonundan biri seçilerek veya JIT ile dinamik olarak yapılabilir
Çalışma zamanında hangi komut zamanlamasının en iyi olduğunu algılamak için gerçek CPU’yu bilmek gerekir
Tüm CPU modellerinin bir tablosu tutulabilir, ama çalışmakta olan CPU’nun bu optimizasyonu uygulayıp uygulamadığı işletim sistemine de sorulabilir
Linux’un, CPU’nun bu optimizasyonu uyguladığını raporlayabilmesi için bir yamaya ihtiyacı vardı
https://www.phoronix.com/news/Intel-5.6-FSRM-Memmove
Intel duyurusunda [1] şu ifadeyi gördüm
Intel, bu sorunu şirket içinde keşfeden Intel çalışanlarına teşekkür ettiğini ve ayrıca bu sorunu bildiren Google çalışanlarına da teşekkür ettiğini söylüyor
[1] https://www.intel.com/content/www/us/en/security-center/advi...
Etki açıklamasını içeren Intel duyurusuna da bakmaya değer: https://www.intel.com/content/www/us/en/security-center/advi...
“Bazı Intel(R) işlemcilerde, işlemci komut dizisi beklenmeyen davranışa yol açarak kimliği doğrulanmış bir kullanıcının yerel erişim yoluyla yetki yükseltme, bilgi ifşası veya hizmet reddi gerçekleştirmesine imkân tanıyabilir”
Paradox Interactive’in Victoria 3 ekibinden Konrad Magnusson, bununla ve mimalloc ile ilgili bir şey bulmuş: https://github.com/microsoft/mimalloc/issues/807
Tamamen ilgili mi bilmiyorum, ama mümkün