Google’ın kernelCTF PoW’unu AVX512 ile nasıl yendiler

 (anemato.de)
2 puan yazan GN⁺ 2025-05-31 | 1 yorum | WhatsApp'ta paylaş
  • Crusaders of Rust ekibi, Linux paket zamanlayıcısında bir use-after-free hatası buldu ve bunun için bir exploit geliştirdi
  • Google kernelCTF yarışmasında hızlı bir PoW (Proof of Work) çözümüne duyulan ihtiyaç nedeniyle yüksek performanslı optimizasyon denendi
  • AVX512IFMA komutlarını kullanan özel assembly ve SIMD optimizasyonu ile mevcut Python/GMP ve Rust uygulamalarına kıyasla yaklaşık 7 kata varan hız elde edildi
  • Çalışma prensibi, modüler aritmetik, bellek yönetimi ve register kullanımı dahil her ayrıntı ince ayar yapılarak PoW işleme süresi 0,21 saniyeye kadar indirildi
  • Sonuç olarak tarihin en kısa süresinde (3,6 saniye) kernelCTF’ye başarılı bir gönderim yapıldı ve ardından PoW politikası resmî olarak kaldırıldı

Genel bakış ve amaç

  • 2025 Mayıs’ında Crusaders of Rust ekibinden William Liu ve Savy Dicanosa, Linux’ta bir use-after-free zafiyeti bulup Google’ın kernelCTF yarışmasına katıldı
  • Bu yazı, PoW (Proof of Work) doğrulamasını hızla çözerek sınırlı ödül rekabetinde diğer küresel ekiplerden daha hızlı gönderim yapabilmek için yürütülen optimizasyon sürecini ele alıyor

kernelCTF gönderim süreci ve rekabet ortamı

  • kernelCTF, yüksek ödül miktarı nedeniyle dünya çapındaki profesyonel güvenlik ekiplerinin gönderim otomasyonu ve PoW optimizasyonuna büyük önem vererek katıldığı bir yarışma
  • Her gönderim penceresinde (iki haftada bir açılıyor) yalnızca en hızlı tek ekip ödül alıyor
  • Gönderim süreci:
    • Sunucuya tam saatte bağlanma
    • Birkaç saniye süren PoW çözümü
    • VM’in açılmasını bekleme
    • Exploit kodunu çalıştırma ve flag alma
    • Google Form gönderimi
  • Son dönemde 4,5 saniyede başarılı flag gönderimi kaydedilmiş olsa da yalnızca PoW ve VM açılışı bile 6,5 saniye sürdüğünden, PoW çözüm hızını artırmak temel bir gereklilikti

PoW (VDF-Sloth) algoritmasının analizi ve ilk optimizasyon

  • kernelCTF PoW’u, sloth VDF adlı sıralı hesaplamaya dayalı bir verifiable delay function kullanıyor
    • 1280 bitlik bir tamsayı x için modüler karesini alma ve bit tersleme işlemleri tekrar ediliyor
  • Mevcut uygulamalarda (Python+gmpy ve Rust) çok çekirdekli paralelleştirmenin zaten fayda sağlamadığı ve GMP’nin de yeterince optimize olduğu görülüyordu
  • Ancak modüler işlemin Mersenne sayısı (2^1279-1) tabanlı olmasından yararlanılarak, daha hızlı bir C++ manuel modulo uygulamasıyla performans 1,9~1,4 saniyeye kadar iyileştirildi

AVX512IFMA’ya büyük geçiş ve SIMD tabanlı ultra hızlı uygulama

  • Sonrasında AVX512 ISA’sına ve özellikle AVX512IFMA’ya (52 bit çarpma ve biriktirme komutları) odaklanıldı
  • 1280 bitlik sayı 52 bitlik limb’lere bölünerek SIMD hızlandırması en üst düzeye çıkarıldı (25 limb → 4 zmm register kullanımı)
  • Modüler kare alma işleminin simetrisi, biriktirme maskeleri, bellek broadcast, register atama optimizasyonu, branch’siz karşılaştırma gibi düşük seviye ayarlar defalarca iyileştirildi
  • ASM (inline assembly) kullanılarak derleyicinin verimsiz register spill/reload davranışı engellendi; broadcast ve masking optimizasyonlarıyla nihai hız 0,21 saniyeye indirildi

PoW gönderim otomasyonu ve gerçek yarışma senaryosu

  • Nihai gönderimde, Google Form’a kadar olan ağ gecikmesini en aza indirmek için Zen 5 Google Cloud sunucusu (Amsterdam bölgesi) kullanıldı
  • Otomatik gönderim programı (Google Form POST isteğinin yamalanması, ekip içi iş birliğiyle optimizasyon) sayesinde rekor süre olan 3,6 saniyede flag başarıyla gönderildi
  • kernelCTF yönetimi resmî olarak PoW politikasını kaldırdığını açıkladı; böylece PoW optimizasyon yarışının sona ermesiyle birlikte kullanılan teknikler de kamuya açıklanabilir hâle geldi

İleri düzey uygulama ayrıntıları

Modüler aritmetik optimizasyonu

  • 2^1279-1 (asal) modunda işlem, bit kaydırma ve birkaç temel aritmetik işleme indirgenerek standart GMP’ye kıyasla çok daha hızlı modüler aritmetik elde edildi

AVX512IFMA tabanlı big-int karesini alma

  • AVX512’nin 52 bit çarpma-biriktirme komutları (vpmadd52luq, vpmadd52huq) kullanılarak 8 limb’lik gruplar üzerinde paralel çarpma ve biriktirme yapıldı
  • Yapı 25 limb’den oluştuğu için veri 4 zmm içine dağıtıldı ve gereksiz masking/biriktirme işlemlerini en aza indiren bir mantık tasarlandı

Veri yerleşimi ve register kullanımı

  • Ofset bazlı birimler, kademeli veri yerleşimi, register’lar arası yeniden hizalama (valignq, broadcast) gibi tekniklerle SIMD darboğazları giderildi
  • Biriktiriciler (accumulator) iki katına çıkarılarak çarpma birimlerinde bekleme olmadan en yüksek throughput sağlandı
  • Carry propagation da yalnızca zorunlu olan en düşük seviyede uygulandı

Nihai gönderim otomasyonu ve ekip çalışması

  • Gece saatlerinde kampanyaya odaklanmak için ekip üyeleri konumlandırıldı; ağ konumu ve exploit çalıştırma süreci optimize edildi
  • Gerçek gönderimde PoW çözümü, exploit çalıştırma, flag yerleştirme ve Google Form POST isteğine kadar tüm süreç uçtan uca otomatikleştirildi

Sonuç ve anlamı

  • kernelCTF PoW optimizasyonu, bit düzeyinden belleğe, register’lara ve CNN’ye kadar donanımı anatomik düzeyde anlamayı gerektiren bir iş
  • PoW politikasının kaldırılmasıyla birlikte rekabetin odağı yalnızca saf ağ/exploit hızı oldu
  • Bu örnek, gerçek dünya hackleme ile yüksek performanslı hesaplamanın kesişimini gösterirken, algoritma optimizasyonu birikimi ve açık kaynak kodun araştırmacı topluluğuna katkı sağlamayı sürdüreceğini ortaya koyuyor

Referans ve ekler

  • PoW algoritmasının tüm kodu ile dönüşüm fonksiyonları (GMP <-> 52 bit dizi), SIMD tabanlı modüler aritmetik ve ASM tuning kodu tamamen yayımlandı
  • Yaklaşık 12 saatlik yoğun geliştirme sürecinin ardından sahada kullanılan “ham” bir kod olsa da GNU AGPL 3.0 lisansı altında açıklandı
  • Sorular veya VDF ile ilgili iş birliği için Discord (@forevermilk) üzerinden iletişime geçilebilir

İlgili okumalar

1 yorum

 
GN⁺ 2025-05-31
Hacker News yorumu

  • 3,6 saniyeyle kazanan takımın ardından ikinci sıradaki ekip de 3,73 ya da 3,74 saniyelik bir derece elde etmiş; bu da ikinci sıradakilerin de PoW optimizasyonu yapmış ya da FPGA kullanmış olabileceğini düşündürüyor. Daha önce 4 saniyenin üzerindeki FPGA gönderimleriyle kıyaslanınca, yazarın bu haftaki ikinci sıra derecesinin de tüm zamanların en iyilerinden biri olabileceğini belirtmesi güzel olurdu

  • Bu yöntemin, AVX-512 ile optimize edilmiş RSA uygulamalarında kullanılan yaklaşıma çok benzediği izlenimi var; sonuçta RSA da çok büyük üs alma işlemleri gerektiriyor. Makalede(https://dpitt.me/files/sime.pdf) windowing tekniği ve pencere boyutunun keyfi olarak ayarlanabilmesi ele alınıyor. AVX-512 RSA uygulamalarında buna ek olarak çarpma sonuçları [0..2^{window-size}) aralığında tabloya yazılıyor ve her pencere için bu sonuçlar kullanılıyor. Somut bir örnek aws-lc kodundaki rsaz-2k-avx512.pl içinde görülebilir

    • Bunları önceden görmüş olsaydım geliştirme sırasında faydalanabilirdim diye bir hayıflanma var. Zen 5'te zmm register'larının kullanımıyla 2 kat çarpma verimi bekleniyor. Mevcut kodda mask register'ları GPR'ye çevriliyor ki bu Zen 4/5'te verimsiz. Carry propagation'ın gerçekten tek seferde yapılmasının gerekip gerekmediği de sorgulanıyor. Kod pratikte yalnızca bir kez carry oluşacağını varsayıp döngüye giriyor; bu da çoğu durumda gecikmeyi azaltmaya yardımcı oluyor. Ancak branch nedeniyle zamanlama saldırısı ihtimali yine de kalıyor

  • AVX512'nin birden çok nesil boyunca tüketici CPU'larında desteklendiği iddiasına karşı, Rocket Lake'e (11. nesil) kadar AVX512'nin yalnızca enthusiast, Xeon ve bazı mobil işlemcilerde mevcut olduğu hatırlatılıyor. 12. nesilde P/E core'ların gelişiyle birkaç ay içinde devre dışı bırakılıp kaybolduğu söyleniyor. AMD AVX512'de başarılı olursa Intel'in tekrar getireceği tahmini de eklenmiş; yorum sahibi kendisinin i9-11900 kullandığını belirtiyor

      1. nesil P-core CPU'lar AVX512 desteğini ne sundu ne de tanıttı; varsayılan olarak da kapalıydı. E-core'ların kapladığı alan nedeniyle tüm CPU üzerinde AVX512 fiziksel olarak yoktu. Yalnızca BIOS'taki bazı hileli seçeneklerle E-core'ları kapatıp kalan core'larda AVX512'yi etkinleştirmek mümkündü; ama bunun bedeli E-core'lardan vazgeçmekti
    • Intel'in yakın tarihli AVX10 teknik belgesinde(https://cdrdv2.intel.com/v1/dl/getContent/784343) hem P-core hem de E-core için 512 bit AVX standart olarak sunuluyor. Bu, yalnızca 256 bit'le sınırlı yapıdan çıkılıp AVX-512'nin sadece sunuculara değil gelecekte tüketici CPU'larına da ciddi biçimde geri döneceğine işaret ediyor. Bu da AMD'nin AVX-512 genişlemesine karşı Intel'in yetişmeye çalıştığı şeklinde yorumlanıyor

  • CTF yarışmasının doğasına dair bir soru var: gönderim hızını yarıştırmak yerine, belirli bir teslim penceresi içinde flag gönderen tüm takımların ödülü paylaşması daha iyi olabilir deniyor

    • Buna karşılık, böyle bir modelin katılımcıları exploit bilgilerini hemen açıklamak yerine sonraki turlarda kullanmak üzere saklamaya iteceği, dolayısıyla anında raporlamayı engelleyen bir metagame yaratabileceği söyleniyor. Ayrıca gönderim zamanlaması gibi yapıcı olmayan rekabet biçimlerini teşvik etme riski de var
    • Metagame yapısının değişeceği ve hatta bunun bazı kişilerin kernelCTF'ye gönderim yapma isteğini azaltabileceği de belirtiliyor

  • Doğru anladıysam burada 4 saniyelik bir proof of work ve ayda bir ödeme yapısı var; gerçekten her ay bu kadar çok exploit çıkıp bu kadar yoğun bir rekabet mi yaşanıyor diye soruluyor

    • Sunucu iki haftada bir açılıyordu ve PoW, aşırı istekleri engellemek için biraz gecikme ekleme amacı taşıyordu. Açık CTF'lerde bazen DDoS benzeri operasyon denemeleri olacak kadar sert rekabet yaşanabiliyor. Sonrasında Google proof of work aşamasını kaldırdı
    • Linux kernel güvenliğine dair anlatının gerçekte bir yanılsamadan ibaret olduğu iddia ediliyor
    • Bu CTF uzaktan kod çalıştırma değil, yetki yükseltme yani normal kullanıcıdan root'a çıkma exploit'leriyle ilgiliydi; yetki yükseltme hataları gerçekten çok yaygın

  • Etkileyici bir başarı ama zafere giden engellerin karmaşıklığı ve işin biraz absürt havası dikkat çekiyor; adeta bir Rube Goldberg makinesi gibi olduğuna dair eğlenceli bir benzetme yapılıyor

  • Metinde geçen base-52 kısmı hakkında daha fazla bilgi isteyenlere, bugün çok ilgi gören şu yazıya(https://news.ycombinator.com/item?id=44132673) bakmaları öneriliyor

  • Matematiğin ne kadar harika olduğuna dair kısa bir hayranlık ifadesi var

  • Proof of work'te kullanılan sloth adlı bir VDF'den (Verifiable Delay Function) bahsediliyor. Bu yapı, zamanın geçtiğini kanıtlamak için uzun bir hesaplama dizisi gerektiriyor; ama sonuç çok hızlı doğrulanabiliyor. Hesaplama seri olduğu için birden fazla core kullanmak çalışma süresini kısaltmıyor. Bunun CPU üreticileri için yeni bir pazar oluşturup oluşturamayacağı sorgulanıyor; sloth iterasyonları ve sonuçları için özel komutlar ile donanım tabanlı overclock engelleme özellikleri öneriliyor. CPU uptime'ını izleyip challenge ile birlikte imzalama fikri de ortaya atılıyor; bu da CPU'yu üretken işlerde kullanırken aynı zamanda n saniye boyunca CPU sahipliğini kanıtlayan bir tür proof of stake'e benzetiliyor

  • Blogdaki Python fonksiyonunun Google'ın PoW uygulamasıyla nasıl eşdeğer olduğu merak ediliyor; takip etmesi zor bulunmuş

    • Google kodunda "exponent = (p + 1) // 4" değerinin 2^1277 olduğu, bir sayıyı bu kadar büyük bir üsse yükseltmek için 1277 kez kare almak gerektiği ve Python fonksiyonunun fiilen bunu yaptığı açıklanıyor. İlk değer x ise, her kare alma adımında üs iki katına çıkıyor ve sonunda 2^1277 elde ediliyor; mantık bu şekilde anlatılıyor