Downfall Saldırısı

 (downfall.page)
1 puan yazan GN⁺ 2023-08-09 | 1 yorum | WhatsApp'ta paylaş
  • Kişisel ve bulut bilgisayarlarda yaygın olarak kullanılan Intel işlemcilerindeki CVE-2022-40982 açığı, aynı bilgisayarı paylaşan diğer kullanıcıların verilerinin çalınmasına olanak tanır
  • Açığın özü, bellek optimizasyonu sürecinde Gather komutunun spekülatif yürütme sırasında dahili vektör kayıt dosyasının içeriğini açığa çıkarmasıdır
  • Saldırı GDS·GVI teknikleriyle uygulanır; demolarda AES anahtarları, Linux Kernel verileri ve yazdırılabilir karakterlerin izlenmesi dahil olmak üzere izolasyon sınırlarını aşan sızıntılar gösterilir
  • Etki alanı Intel Core 6. nesil Skylake’ten 11. nesil Tiger Lake’e kadardır; bulut kullanıcıları Intel cihazlarına doğrudan sahip olmasalar bile etkilenebilir
  • Intel’in mikrokod güncellemesi Gather’ın transient sonuçlarını engeller, ancak bazı iş yükleri azaltma uygulandıktan sonra %50’ye varan ek yük yaşayabilir

Downfall’ın hedef aldığı açık

  • Downfall, kişisel bilgisayarlarda ve bulut bilgisayarlarında kullanılan modern işlemcilerdeki önemli bir zayıflığı hedef alır
  • Bu açık CVE-2022-40982 olarak tanımlanır
  • Aynı bilgisayarı paylaşan diğer kullanıcıların verilerine erişip bunları çalabilir
    • Uygulama mağazasından indirilen kötü amaçlı bir uygulama; parolalar, şifreleme anahtarları, banka bilgileri, kişisel e-postalar ve mesajlar gibi hassas bilgileri ele geçirebilir
    • Bulutta kötü amaçlı bir müşteri, aynı bulut bilgisayarını paylaşan diğer müşterilerin verilerini ve kimlik bilgilerini çalabilir

Açığın teknik nedeni

  • Intel işlemcilerindeki bellek optimizasyonu özelliği, dahili donanım kayıtlarını istemeden yazılıma açar
  • Güvenilmeyen yazılımlar, normalde erişememesi gereken diğer programların verilerine erişebilir
  • Bellekte dağınık halde bulunan verileri daha hızlı okumaya yarayan Gather komutu, spekülatif yürütme sırasında dahili vektör kayıt dosyasının içeriğini sızdırır
  • Bunu kötüye kullanan teknikler olarak Gather Data Sampling(GDS) ve Gather Value Injection(GVI) kullanılır
  • Teknik ayrıntılar Downfall makalesinde derlenmiştir

Demolarda doğrulanan sızıntı örnekleri

  • Downfall demoları, farklı izolasyon sınırları aşılarak hassas verilerin sızdırılabileceğini gösterir
    • Video 7: Başka bir kullanıcının 128-bit ve 256-bit AES anahtarlarının ele geçirilmesi
    • Video 8: Linux Kernel içinden rastgele verilerin ele geçirilmesi
    • Video 9: Yazdırılabilir karakterlerin izlenmesi

Etkilenen sistemler ve saldırı koşulları

  • Etkilenen cihazlar, Intel Core 6. nesil Skylake’ten 11. nesil Tiger Lake’e kadar olan işlemcilere dayalı bilgi işlem cihazlarıdır
  • Etkilenen işlemcilerin daha kapsamlı listesi Intel’in affected processors listesinde sağlanacaktır
  • Fiziksel bir Intel tabanlı cihaza sahip olmasalar bile bulut kullanıcıları etkilenebilir
    • Intel’in sunucu pazar payı %70’in üzerindedir
  • Saldırganlar parolalar ve şifreleme anahtarları gibi yüksek değerli kimlik bilgilerini hedefleyebilir
  • Kimlik bilgisi hırsızlığı, gizliliğin ihlalinin ötesinde bilgisayarın erişilebilirliğini ve bütünlüğünü zedeleyen başka saldırılara yol açabilir
  • GDS’nin gerçek bir saldırı olarak uygulanması görece kolaydır
    • OpenSSL’den şifreleme anahtarlarını çalan uçtan uca bir saldırı geliştirmek 2 hafta sürdü
    • Saldırgan ile kurbanın aynı fiziksel işlemci çekirdeğini paylaşması yeterlidir
    • Öncelikli çoklu görev ve eşzamanlı çoklu iş parçacığı kullanan modern bilgisayarlarda bu tür paylaşım sıkça gerçekleşir

İzolasyon sınırları, SGX ve tarayıcı etkisi

  • Downfall yaygın izolasyon sınırlarını da etkiler
    • Sanal makineler
    • Süreçler
    • Kullanıcı-çekirdek izolasyonu
  • Intel SGX de etkilenir
    • Intel SGX, kullanıcı verilerini kötü amaçlı yazılımlardan korumaya yönelik Intel CPU’larının donanım güvenliği özelliğidir
  • Web tarayıcıları üzerinden uzaktan kötüye kullanım teorik olarak mümkündür
    • Tarayıcıda başarılı bir saldırı göstermek için ek araştırma ve mühendislik çalışması gerekir

Maruz kalma süresi ve tespit zorluğu

  • Kullanıcılar bu açığa en az 9 yıl boyunca maruz kalmıştır
    • Etkilenen işlemciler 2014’ten beri mevcuttur
  • Downfall saldırılarını tespit etmek zordur
    • Çalışma biçimi çoğunlukla normal bir uygulama gibi görünür
    • Teorik olarak donanım performans sayaçları kullanılarak aşırı cache miss gibi anormal davranışları tespit eden bir sistem kurulabilir
    • Yaygın ticari antivirüs yazılımları bu saldırıyı tespit edemez

Azaltma önlemleri ve performans ek yükü

  • Intel bir mikrokod güncellemesi dağıttı
    • Bu güncelleme Gather komutunun transient sonuçlarını engeller
    • Saldırgan kodunun Gather’dan çıkan spekülatif verileri gözlemlemesini önler
  • Azaltma önleminin ek yükü, programın kritik yürütme yolunda Gather bulunup bulunmamasına bağlıdır
  • Intel’e göre bazı iş yükleri %50’ye varan ek yük yaşayabilir
  • İş yükünün Gather kullanmadığı düşünülerek azaltma önlemini kapatmak güvenli değildir
    • Modern CPU’lar, bellek kopyalama ve kayıt içeriği geçişi gibi genel işlemleri optimize etmek için vektör kayıtlarını kullanır
    • Bu süreçte, Gather’ı kötüye kullanan güvenilmeyen kod aracılığıyla veriler sızdırılabilir

Açıklama takvimi ve yeniden üretim kodu

  • Bu açık neredeyse 1 yıl boyunca ambargo altındaydı
  • Intel’e 24 Ağustos 2022’de bildirildi
  • Downfall, 9 Ağustos 2023’te BlackHat USA ve 11 Ağustos 2023’te USENIX Security Symposium etkinliklerinde sunuldu
  • Yeniden üretim kodu GitHub POC üzerinde yayımlanmıştır

Diğer işlemci tasarımcılarının dikkat etmesi gerekenler

  • Diğer işlemciler de çekirdek içinde donanım kayıt dosyaları ve fill buffer gibi paylaşımlı SRAM belleklerine sahiptir
  • Üreticiler, farklı güvenlik alanları arasında veri sızmaması için paylaşımlı bellek birimlerini daha dikkatli tasarlamalıdır
  • Güvenlik doğrulama ve testlerine daha fazla yatırım yapmalıdırlar

Adı ve ilgili açıklar

  • Downfall adı, çoğu bilgisayarın temel güvenlik sınırlarını yıkması anlamıyla verilmiştir
  • Downfall, CPU’lardaki önceki veri sızıntısı açıkları olan Meltdown ve Fallout için bir devam niteliğinde görülebilir
  • Bu çizgide Downfall, önceki azaltma önlemlerini yeniden aşar

Tedarikçi önerileri ve teknik belgeler

İlgili okumalar

1 yorum

 
GN⁺ 2023-08-09
Hacker News yorumları

  • İlk Spectre saldırısından sonra bile dış araştırmacıların benzer saldırıları bulmaya devam etmesi ve çip üreticilerinin bunları sonradan yamalaması tuhaf geliyor
    İlke olarak çip üreticileri spekülatif yürütme konusunda uzman; çipin nasıl çalıştığını tam olarak biliyorlar ve doğrulama paketlerine, simülatörlere, hatta makine tarafından okunabilir iç spesifikasyonlara sahipler; dolayısıyla bunları bulmak için en avantajlı konumda olmaları gerekir
    Dış araştırmacılar ise kara kutuyu kurcalamak ve patentler gibi çok daha zayıf kaynaklarla tersine mühendislik yapmak zorunda; buna rağmen aradan yıllar geçmesine karşın bireyler ya da dış gruplar bu tür açıkları hâlâ bulabiliyor
    Spectre’den önce bu saldırı vektörlerini düşünmemiş olabilirler; ama genel mekanizma ortaya çıktıktan sonra çip üreticilerinin en zeki insanlarını toplayıp “her yeri didik didik edin ve başka Spectre türü saldırılar bulun” demiş olması gerekmez miydi diye düşünüyor insan
    Belki de hepsini zaten biliyorlar ama itibar kaybından ve performans düşüşünden kaçınmak için kamuya açıklanmamasını umarak üstünü örtüyorlardır

    • Bu sağ kalan yanlılığı olabilir. Açıklanmadan yamalanan Spectre türü hataların ne kadar çok olduğunu bilemeyiz
    • Bu mantık rahatsız edici geliyor. Aynı düşünce tarzıyla, bellek güvenliği hatasını iki kez yapan bir programcının da bunun sadece insani bir hata değil, kötü niyetli olduğu varsayılabilir
      Milyarlarca kişinin kullandığı bir şey söz konusuysa, onu yapanlardan daha fazla sorun, kusur ve exploit bulunacağını düşünüyorum. Böyle sorunların var olması tek başına, nedenleri hakkında ek bir sonucu ne destekler ne de çürütür
    • Henüz kimsenin dile getirmediği bir olasılık da şu: Çip üreticilerinin bunları bulmak için çok zaman harcamamasının nedeni, aslında o kadar da önemli olmamaları olabilir
      Güvenlik araştırmacısının, itibar kazanmak için bir şeyler bulma teşviki vardır. Gerçek saldırganlar için pek bir anlamı olmasa bile bunu sık sık dünyayı sarsacak bir güvenlik açığı gibi sunarlar
      Gerçek ortamlarda spekülatif yürütme saldırısı hiç bulundu mu? Muhtemelen bulunmamış olabilir. Öyleyse çip üreticisinin buna muazzam para harcaması için güçlü bir gerekçe yok
      Gerçek müşteriler, dış araştırmacıların önlem alınmasını zorlayıp performansı yavaşlatan yeni mikrokod çıkarılmasına neden olduğu durumlar dışında zarar görmez
      Bu saldırıların hafifletme önlemlerine her zaman kapatma anahtarı eklenmesi de dikkate değer. Güvenlik düzeltmelerinde sık görülen bir biçim değil; çünkü çoğu durumda bu saldırılar pek önemli değil
      Aynı fiziksel çekirdekte ya da aynı fiziksel CPU’da çalışan yazılımlar aynı güven düzeyindedir veya saldırıyı gerçekleştiremeyecek kadar güçlü biçimde sandbox’a alınmıştır
    • Kernighan’ın hata ayıklama yasasına takılmış olabilirler. “Herkes bilir ki hata ayıklama, programı ilk başta yazmaktan iki kat zordur. O halde yazarken mümkün olduğunca zekice yaptıysanız, onu nasıl hata ayıklayabilirsiniz ki?”
      Intel, hiç kuşkusuz çipleri “mümkün olduğunca zekice” yapıyor; bu yüzden tanım gereği tamamen hata ayıklanamazlar
    • Bir CPU mühendisi olarak söyleyeyim: Spectre, daha önce savunmasız olduğunu düşünmediğimiz bir bilgi sızıntısı kanalını ortaya çıkardı. Bu yüzden yeni exploit’ler peş peşe geldi; merkezinde yeni bir fikir vardı ve başkaları da o fikrin üzerine inşa etti
      Bunların hata olmadığını da vurgulamak önemli. Tasarım amaçlandığı gibi çalışıyor. CPU’nun, daha önce çalıştırdığı koda bağlı olarak performansının değiştiğini anlıyorduk; alternatifin güç, performans ve alan açısından maliyetinin çok yüksek olduğuna karar verilmiş ve bu kabul edilmişti. Mühendislik budur: alternatifleri tartıp seçim yapmak
      Bu örnekte CPU yeterince hızlanınca, yineleme başına bitin küçük bir bölümü saldırılabilir bant genişliğine dönüştü; ama sektörün bunu anlayabilmesi için birinin bunu göstermesi gerekiyordu. Mühendislik değerlendirmesini değiştiren de bu oldu

  • Intel makalesinin bağlantısı ölmüş; doğru bağlantı şu gibi görünüyor: https://www.intel.com/content/www/us/en/developer/articles/t...
    Genel bir not olarak, hâlâ farklı kullanıcıların iş yüklerini aynı fiziksel çekirdekte çalıştıran çok sayıda bulut var mı? Çoğunun birkaç yıl önce zamanlayıcılarını değiştirip hyper-thread’ler arasındaki çapraz alan sızıntılarını engellediğini sanıyordum.
    İnternetteki tüm kullanıcıları etkilediği iddiası bana aşırı abartı gibi görünüyor. Tarayıcı tabanlı bir exploit de görünmüyor; var olsa bile yalnızca hedef alınan çok küçük bir kullanıcı grubunu etkilerdi. Spectre’ın çıkmasının üzerinden yıllar geçti; gerçek ortamlarda spekülatif yürütme saldırıları hiç tespit edildi mi, emin değilim.
    Daha ilginç olan, bu spekülatif yürütme hatalarının sürekli olarak mikrokodla yamalanabilir görünmesi. İlk ortaya çıktıklarında fiziksel çiplerin topluca hurdaya çıkarılıp değiştirilmesi gerekebileceği korkusu vardı; ama gerçekten böyle bir şeyin gerekli olduğu oldu mu?
    Bildiğim kadarıyla tüm hatalar yazılım ve mikrokod değişikliklerinin bir kombinasyonuyla ele alınabildi; bazı durumlarda yalnızca bir miktar performans maliyeti ödendi. Yeni silikon gerektiren bir hata olmadı. İstisna olarak, erken AMD SEV sürümleri gibi gerçekten yamalanamaz biçimde jailbreak edilmiş durumlar sayılabilir.

    • AWS/GCP/Azure gibi büyük bulutlar olmayan VPS sağlayıcıları çok fazla ve orada yanıt “evet”. ‘Ayrılmış’ çekirdek sattığını söyleyen yerlerde bile bu çoğu zaman CPU kullanımını sınırsız verdikleri anlamına geliyor.
    • Spectre saldırılarının çekirdekte yamalanması gerekti ve Intel CPU’ların çalışma hızını ciddi ölçüde yavaşlattı: https://www.notebookcheck.net/Spectre-v2-mitigation-wreaks-h...
    • AWS’nin t instance’ları tam da bu amaç için değil mi? Çekirdek düzeyinde “paylaşıldığını” anlıyordum; öyle değilse CPU kredi bakiyesi gibi bir kavramın var olması için sebep yok.
    • Çoğu, hatta belki neredeyse tüm bulut VM’lerinin çekirdekleri ayrılmış olarak verdiğini düşünüyorum.
      Elbette AWS’nin T serisi gibi paylaşılanlar da var; diğer bulutlarda da benzerleri olmalı. Ama kullanıcılar arasına ek “flush” koyarak tenant’lar arası sızıntının önlenebileceğini düşünüyorum.
      Tabii tek bir tenant içindeki süreçler arası sızıntı, bulutta da on-premise’te de bir sorun; nihayetinde kendi makinenizdeki süreçlerin kötü niyetli hâle gelmeyeceğine ne kadar güveneceğinize karar vermeniz gerekiyor.
    • “İnternetteki herkes”i etkileyebilme ihtimalinden söz edilmesinin nedeni, çoğu sunucunun savunmasız olması.

  • Farklı güvenlik alanlarına ait kodları aynı fiziksel işlemci çekirdeğinde çalıştırmayı doğru yapmak imkânsız görünüyor; artık bundan vazgeçmek gerek gibi.
    Yaygın durumlar aslında yalnızca VM ve JavaScript olmak üzere iki tane.
    VM’lerden vazgeçmek gerekiyor. Belirli çekirdekler belirli VM’lere ya da en azından belirli müşterilere ayrılmalı.
    JavaScript biraz daha zor.
    Her iki durumda da genel durumda performanstan vazgeçilmemeli.

    • JavaScript için “bunu artık bırakalım” demek makul görünüyor.
    • Burada çok çekirdeği yeniden öne çıkaracak bir pazarlama fırsatı var. Çoğu iş yükü, CPU’ya daha fazla çekirdek eklemenin azalan getiri noktasına ulaştı; ama daha fazla eşzamanlı süreç ya da tarayıcı sekmesini güvenli biçimde çalıştırmak için daha fazla çekirdeğe ihtiyaç olduğu sonucuna varılırsa, 128 çekirdekli dizüstü çipleri ortaya çıkabilir.
    • CPU’yu “IOPU” ve “SPU” olarak ikiye ayırmanın mantıklı olup olmadığını bir süredir merak ediyordum.
      IOPU sistemdeki diğer donanımları yönetme görevini üstlenir ve çok yüksek performanslı olması gerekmez.
      SPU ise hızlı çalışması gereken skaler kod ve dallanması yoğun kod için optimize edilir.
      SPU’nun, RAM’den getirirken rastgele belleği okuyamamasını sağlayacak düzeyde asgari güvenliğe sahip olması yeterli olur. Aynı anda yalnızca tek bir program çalıştıracağı için spekülatif yürütme sorun olmaz.
      Benim sistemimde çok işlem gücü gerektiren az sayıda program var; gerektiğinde de aralıklı oluyor, bu yüzden SPU’da çok fazla görev geçişi olacağını sanmıyorum.
    • Doğru. Bu yaklaşım altın çağını geride bıraktı. 1960’lardan 1990’lara uzanan zaman paylaşımlı sistemler dönemi; yani üniversitelerde veya ISP’lerin Unix sistemlerinde birden çok kullanıcının shell hesabına sahip olduğu zamanlar.
      Bu tür CPU saldırıları, kullanıcıların keyfî makine kodu çalıştırdığı güvenli zaman paylaşımlı sistemlerin artık gerçekçi olmadığını gösteriyor.
      Aynı projede çalışanların bir build makinesini paylaşması gibi birbirine güvenen taraflar arasındaki zaman paylaşımı ise varlığını sürdürecektir.
    • İstatistiksel mekaniğin gelip açıklığa kavuşturmasından önceki termodinamiğin ikinci yasasına benziyor. Analitik ve felsefi olarak sağlam temellendirilmiş olmayabilir, ama deneysel olarak o kadar güçlü ki tersini satmaya çalışan biri son derece şüpheli görünür.
      Bir bilgisayarda çalışan iki programın birbirini gözetlemesini engelleyebileceğimiz fikri de bu düzeyde.

  • Intel güvenlik duyurusu: https://www.intel.com/content/www/us/en/developer/articles/t...
    Linux çekirdeği birleştirmesi: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

  • Yalnızca 11. nesle kadar etkili olması, bu açığın Intel’e açıklandığı zamanlamanın 12. nesilde düzeltilebilecek kadar erken olduğunu düşündürmüyor. O halde başka bir şeyi düzeltirken tesadüfen çözülmüş olabilir mi diye düşünüyorum
    Makaleye bakınca şöyle deniyor: “Intel, Alder Lake, Raptor Lake, Sapphire Rapids gibi yeni CPU’ların etkilenmediğini belirtti. Ancak bunun güvenlik kaygısından ziyade büyük ölçüde değişen mimarinin bir yan etkisi olduğu görülüyor”
    Sonuçta rastgele düzeltilmiş ya da en azından bu belirli exploit’in çalışamaz hâle gelmiş olması söz konusu

    • Mikromimari davranışı nesilden nesle değişir; dolayısıyla yan etkiler de değişir. Tesadüfen bir sorunu düzeltmek de, tesadüfen yeni bir sorun yaratmak da nispeten sık olur

  • FAQ’ya göre kullanıcılar bu açığa en az 9 yıl boyunca maruz kalmıştı. Çünkü etkilenen işlemciler 2014’ten beri vardı
    Böyle açıkların yıllarca fark edilmemesi, ama birinin exploit kodlamasının yalnızca 2 hafta sürmesi şaşırtıcı

    • En başta açığı bulma süresi muhtemelen 2 haftadan çok daha uzundu
    • Açığın yayımlanmış olması yalnızca bir white hat ya da gray hat araştırmacının açığı bulduğu anlamına gelir. Bu arada daha az vicdanlı tarafların aynı kusuru kullanıp kullanmadığını, kaç kez kullandığını bilmenin yolu yok
    • Büyük olasılıkla önceki exploit’ler temel alınarak yapılmış bir çalışma

  • LWN yazısına bakın: https://lwn.net/Articles/940783/
    Linux’ta güncellenmiş mikrokodu olmayan CPU’lar için bu sorunun azaltma önlemi olarak AVX tamamen devre dışı bırakılıyor. Bana göre epey sert ve hissedilir etkisi de büyük olacak gibi. Şimdi güncellenmiş mikrokod alıp alamayacağımı öğrenmek istiyorum

    • AVX’in devre dışı bırakılması yalnızca gather_data_sampling=force kullanıldığında uygulanıyor. Varsayılan değer AVX’i olduğu gibi bırakıp sistemi savunmasız olarak işaretlemek
      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... içinde görüldüğü üzere:
      gather_data_sampling=force belirtilirse mümkün olduğunda mikrokod azaltma önlemi kullanılır; bu azaltma önlemini içerecek şekilde mikrokodu güncellenmemiş etkilenen sistemlerde ise AVX devre dışı bırakılır
      Not olarak, Intel’de Linux üzerinde çalışıyorum. İnsanların kafasını karıştıran belgeleri ve değişiklik günlüklerini yazmış ya da elden geçirmiş olma ihtimalim yüksek
    • [ 0.000000] microcode: updated early: 0x27 -> 0x28, date = 2019-11-12
      Haswell kullanıyorum. Hangi CPU’ların güncellenmiş mikrokod aldığını gösteren bir liste var mı? Yazık
    • Varsayılan değer olmayabilir. Metinden bakınca tamamen net değil

  • GCP’nin bu sorunu yamaladığını da belirtmek gerekir: https://cloud.google.com/support/bulletins#gcp-2023-024

    • London’da Google Cloud (GCE) SRE olarak çalışan komşu ekipler yamaları zamanında dağıttı ve bugün hak ettikleri donut’ları aldılar
    • Karşılık gelen AWS duyurusu: https://aws.amazon.com/security/security-bulletins/AWS-2023-...
      AWS müşterilerinin verileri ve instance’ları bu sorundan etkilenmez; müşterilerin yapması gereken bir işlem de yoktur
      AWS, bu tür sorunlara karşı korumaya sahip bir altyapı tasarlayıp uygulamıştır. Lambda, Fargate ve diğer AWS yönetimli compute ve container hizmetleri dâhil olmak üzere Amazon EC2 instance’ları, mikrokod ve yazılım tabanlı azaltma önlemleriyle müşteri verilerini GDS’ye karşı korur

  • Performans darbesi çok büyük. En fazla %50 olduğu iddia ediliyor ve güncel Intel işlemcilerin %70’inin etkilendiği söyleniyor

    • “Red Hat’in dahili performans testlerinde en kötü mikrobenchmark büyük bir yavaşlama gösterdi. Ancak vektör gather’dan yararlanan daha gerçekçi uygulamalarda yavaşlama yalnızca düşük tek haneli yüzde seviyelerinde kaldı.”
      https://access.redhat.com/solutions/7027704
      Performans etkisi, Intel Advanced Vector Extensions’ın (AVX2 ve AVX-512) sağladığı gather komutunu ve CLWB komutunu kullanan uygulamalarla sınırlı. Gerçek performans etkisi, uygulamanın bu komutları ne kadar kullandığına bağlı
      Kullanıcı kapsamlı bir risk analizinden sonra azaltma önlemini kapatmaya karar verdiyse — örneğin sistem çok kiracılı değilse ve güvenilmeyen kod çalıştırmıyorsa — azaltma önlemi devre dışı bırakılabilir
      Mikrokod ve kernel güncellemelerini uyguladıktan sonra kernel komut satırına gather_data_samping=off ekleyerek azaltma önlemi kapatılabilir. Ya da GDS dâhil tüm CPU spekülatif yürütme azaltma önlemlerini kapatmak için mitigations=off kullanılabilir
    • O %50 ek yük “Gather” komutu için mi? Öyleyse iş yükündeki komutların %10’u gather ise toplam ek yük %5 olur
    • İfade “bazı iş yükleri %50’ye kadar ek yük yaşayabilir” şeklinde. Bazı iş yükleri denmesine bakılırsa performans darbesi nadir olacak gibi
    • Eksik olan temel bağlam şu: “Programın kritik yürütme yolunda Gather olup olmamasına bağlı”
    • “%70’e varan indirim” ifadesini görüp bunun muazzam bir kampanya olduğunu sanmaya benziyor. Bazen tüm mağazada %70 indirimli yalnızca iki ürün vardır
      “En fazla” iddialarına her zaman şüpheyle yaklaşırım

  • NES’te 6502’nin tamamının gömülü olduğu bir yonga seti vardı; bugün bir pizza fiyatına, kalıbın üzerine karma çekirdekler yerleştirilmiş bir Rockchip ARM çipi satın alabiliyorsunuz. Çip üreticilerinin tüm uç durumları sonsuza dek çözmesi gerekmeyebilir; belki de bu tür yan kanal saldırısı azaltımlarını, çipleri tüketen bizlere geri devredebilirler
    SMT’yi tamamen açık ya da tamamen kapalı bir seçenek yapmak yerine, güvenilmeyen kodu “berbat çekirdeklere” gönderip, müşterinin SMT’li çekirdeklere yükseltilebileceğini “kanıtlamasını” sağlasak nasıl olur?
    Kimse, başka hiçbir şeyin panoya konulamayacağı kadar kritik maaş bordrosu işlerini çalıştıran çipleri mahvetmek istemez. Ama SMT’de güvenle çalıştırılabilecek şeyleri etiketlemeye zorlanmak ve aksi halde daha güvenli çekirdeklere bağlanmak bana makul geliyor
    Bunun ne olduğuna dair hiçbir fikri olmayan bir stajyer arama yaparken bu saldırı vektörünün gerçekte ne olduğunu öğrenip bir savunma planı bile hazırlayabilir
    Garip olan ben miyim?

    • Bence bu piyasanın sorunu
      Performans çekirdeği × verimlilik çekirdeği mümkün
      Ama güvenilir çekirdek × “berbat” güvenilmeyen çekirdek öneren kişi olmak istemezsiniz. Avantajları ne kadar çok olursa olsun, “endişe yaratıyor” söyleminin içinde gömülüp gider. Hayat böyle