Bellek güvenliği mutlakiyetçileri

• Rust’ı yalnızca unsafe var diye dışlayıp yalnızca Fil-C’yi güvenli sayan ölçüt, gerçek yazılımların uygulanabilirlik alanını ve teknik ödünleşimleri gözden kaçırıyor
• Fil-C, C/C++’taki hatalı bellek erişimlerini paniğe çeviriyor; ancak bunun bedeli olarak ABI uyumsuzluğu, bazı durumlarda katlarca performans düşüşü ve GC kullanımı geliyor
• Android’deki yaklaşık 5 milyon satır Rust kodunda, sürüm öncesinde düzeltilen 1 potansiyel bellek güvenliği açığı bulundu; bu da milyon satır başına 0,2 olarak hesaplandı ve C/C++ için geçmişteki yaklaşık 1.000 vakaya kıyasla 1.000 kattan fazla daha düşüktü
• Tüm programlarda sorunların %99,9’unu engelleyen bir teknoloji ile programların %90’ında sorunların %100’ünü engelleyen bir teknoloji arasında yalnızca birini seçmek gerekmiyor; Fil-C’nin kısıtlarını kabullenmesi zor olan yazılımlar için Rust gibi alternatifler daha uygun
• Bellek güvenliği değerlendirilirken performans, ABI, GC ve veri yarışı önleme birlikte ele alınmalı; Rust’ın bile yetersiz olduğu savunuluyorsa, en azından sıradan C/C++ ile Fil-C olmayan Zig’e de aynı ölçüt uygulanmalı

---

Rust ve geleneksel sistem dillerinin sorumluluk modeli

• GC’siz sistem programlama dillerinde bellek güvenliği tartışması çoğunlukla Rust ile C/C++/Zig’in sorumluluk modelleri arasındaki fark etrafında yürüdü
  • Rust, güvenli olabilecek bazı programları da reddetme pahasına, bellek güvenliği sorunlarına yol açabilecek programların derlenmesini engellemeye çalışır
  • unsafe, ham işaretçi çözümleme gibi işlemlere izin vererek bazı güvenceleri aşmaya yarayan bir kaçış kapısıdır
  • C ailesi dilleri ise bellek güvenliği güvencelerinin çoğunu programcıya bırakır
• C++’ın RAII ve akıllı işaretçileri, Zig’in defer özelliği gibi dil desteği düzeyleri farklı olsa da, hatalı bellek erişimini ilkesel olarak engellemezler

Fil-C’nin eklediği seçenek

• Fil-C, C ve C++ kodunu bellek güvenli biçimde çalıştırmak için yeni bir yaklaşım sunuyor
  • Sınır dışı erişim veya serbest bırakıldıktan sonra kullanım gibi hatalı bellek erişimleri meydana geldiğinde panic oluşturuyor
  • GC ile, işaretçilerin erişebileceği belleği izleyen InvisiCaps mekanizmasını birleştiriyor
• Zig için de Fil-C’den ilham alan yeni bir derleme modu önerildi
• Bazı popüler C/C++ projeleri Fil-C ile derlenmiş sürümler sunarsa, bellek güvenliği açıklarını azaltmak için seçenekler artabilir

Rust’ı güvenli saymayan ölçüt

• Fil-C geliştiricisi, Twitter üzerinde unsafe ile bazı güvencelerin aşılabildiği gerekçesiyle Rust’ı bellek güvenli bir dil saymadığını savundu
• Zig geliştiricisi Andrew Kelley de ilgili hata başlığında, Fil-C’den ilham alan modu “Rust’tan farklı olarak gerçekten bellek güvenli” bir derleme modu olarak tanımladı
• Bazı tartışmalarda, Rust kullanıcılarının bellek güvenliğini gerçekten önemsiyorlarsa Rust’ı bırakıp daha güvenli Fil-C’yi öne çıkarması gerektiği öne sürülüyor
• Bu ölçüt, Fil-C’nin pratik maliyetlerini dışarıda bırakarak Rust ile Fil-C’yi karşılaştırıyor ve zaman zaman Rust topluluğuna yöneltilen fanatiklik eleştirisine benzer bir tutum sergiliyor

Fil-C’nin uygulama kısıtları

• Fil-C, maliyetsiz bir drop-in replacement değildir
  • Fil-C olmadan derlenmiş programlarla ABI uyumlu değildir
  • Bazı durumlarda birkaç kat daha yavaş olabilir
  • GC getirir
• Basit yardımcı araçlar gibi performans düşüşünün zor hissedildiği veya dinamik bağlamanın gerekmediği programlarda bu kısıtlar belirleyici olmayabilir
• Buna karşılık, GC’yi ve ABI uyumsuzluğunu kabul edemeyecek pek çok popüler proje vardır; mevcut haliyle Fil-C’nin uygulanmasının zor olduğu programlar ise çoğu zaman Rust’a iyi uyar

Gerçek Rust kodundaki açık verileri

• Rust’ın pratik güvenliğini değerlendirecek veri hâlâ sınırlı, ancak Rust yazılımlarında istismar edilebilir bellek güvenliği açıkları çok sayıda bulunmuş değil
• Android’deki 5 milyondan fazla satır Rust kodunda 1 potansiyel bellek güvenliği açığı bulundu ve sürümden önce düzeltildi
  • Tahmini açık yoğunluğu milyon satır başına 0,2
  • Android’in geçmiş C/C++ verisi milyon satır başına yaklaşık 1.000
  • Rust kodundaki yoğunluk, C/C++’a göre 1.000 kattan fazla daha düşük olarak izleniyor
• Rakamlar projeden projeye değişebilir, ancak bu veriler Rust’ın gerçek dünyada bellek güvenliği sorunlarını koda katma riskini büyük ölçüde azalttığını gösteriyor

Neden yalnızca birini seçmek gerekmiyor

• Tüm programlarda sorunların %99,9’unu engelleyen bir teknoloji ile programların %90’ında sorunların %100’ünü engelleyen bir teknoloji arasında yapılan varsayımsal karşılaştırma, hem kapsama alanının hem de önleme düzeyinin önemli olduğunu gösteriyor
• Gerçek oranlar bilinmese de bu iki yaklaşımdan yalnızca birini seçmek gerekmiyor
  • Ödünleşimleri kabul edebilen C/C++/Zig projeleri Fil-C ikilileri sunabilir
  • Fil-C kullanamayan yazılımlar ise bellek güvenliği açığı riskini tamamen ya da büyük ölçüde ortadan kaldıran dillerle yazılabilir

GC kullanılabilse bile neden Rust seçilir

• Go veya Fil-C gibi GC tabanlı seçenekler varken de Rust kullanmak mantıklıdır
• GC tabanlı bir dille yazılabilen programlarda çoğu zaman unsafe gerekmez; unsafe gerektiren programlarda ise çoğu zaman GC kullanılamaz
• Daha küçük bir bellek güvenliği riskindense veri yarışı önleme gibi başka dil güvenceleri ve özellikleri daha önemli görülebilir
• Fil-C, mevcut C/C++’taki bellek güvenliği açıklarını çökme hatalarına dönüştürür
  • Bu, güvenlik açığından iyidir; ancak geçmiş yoğunluk milyon satır başına yaklaşık 1.000 olarak kalıyorsa düzeltilmesi gereken çok sayıda çökme hatası kalır
  • Geçmişte, saldırganın programı çökertme yeteneğinin kullanıldığı güvenlik açıkları da vardı

Tutarlı bir bellek güvenliği ölçütü

• Rust için milyon satır başına 0,2 vaka bile kabul edilemezse, sıradan C/C++ ve Fil-C olmayan Zig için de aynı ya da daha katı eleştiri uygulanmalı
• Rust’tan daha az güvenli alternatifleri kabul edip yalnızca Rust’ı unsafe yüzünden dışlamak, bellek güvenliği mutlakiyetçiliğini tutarlı biçimde uygulayamamak anlamına gelir

[GN⁺]

Lobste.rs yorumları

• OP’nin rahatsız olmuş göründüğü Andrew Kelly’nin açıklaması, Zig’in C/C++ bağımlılıklarının tamamını bile kaçış yolu olmadan tamamen bellek güvenli yürütülebilir dosyalar olarak derleyebileceği ve işaretçi izleme sıklığına bağlı olarak performans maliyetinin yaklaşık 1 ila 6 kat olduğu yönünde
  Yazar bunu Rust’a yönelik bir saldırı olarak alıyor ve yazının sonunda Zig’e saldırıyor; ancak Fil-C ve Zig’in yeni derleme modu ekosisteme olumlu bir katkı ve Rust’tan farklı tasarım noktaları ile ödünleşimler sunuyor
  Bunu, Zig ekibinin tercih ettiği veri odaklı programlama izlenirse performans maliyetinin 1 kata yakın düşürülebileceği anlamında yorumluyorum

  • Yazar, “Fil-C’den esinlenen, Rust’ın aksine gerçekten bellek güvenli derleme modunun getirilmesi” başlığına ve Fil-C geliştiricisinin Twitter paylaşımına yanıt veriyordu
    Bunu gereksiz yere kışkırtıcı okumak da haksız sayılmaz; Andrew daha sonra başlığı daha az tahrik edici olacak şekilde değiştirdi

• Alışılmışın tersine, “sizin diliniz bellek güvenli değil” şeklindeki hafif bir alay kendilerine yönelince Rust geliştiricilerinin tepki ölçeği epey büyüktü
  Ben de Rust’ı çok seviyorum ama adil yaklaşmak gerekiyor

  • “Rust oldukça bellek güvenli, ama Fil-C bu açıdan daha güvenli” demek pek tartışmalı değil ve doğru görünüyor
    Daha da ötesi, seL4’ün biçimsel olarak doğrulanmış C’si daha da güvenli
  • Doğru programlara önem verdiğim ve mümkün olduğunca doğru olmayan kod yazmak istemediğim için, paradoksal biçimde Zig yerine Rust’ı tercih ediyorum
    Zig’in bellek ayırma başarısızlığında doğru şekilde çıkmayı kolaylaştırması ve hızlı derlenmesi gibi avantajları var
    Fil-C’nin Rust’tan daha bellek güvenli olup olmadığını bilmiyorum, ama benim kullanımımda çöp toplayıcı ve C ABI uyumsuzluğu belirleyici engeller
    Tek iş parçacıklı yaparsanız yarış durumlarından kaçınabilir, çöp toplayıcı eklerseniz bellek güvenliği elde edebilirsiniz; Rust’ın ise bu iki ödünü vermeden ikisini de sunması hoşuma gidiyor

• Bellek güvenliğine çok önem verdiğim için Fil-C ve Zig’in Fil-C ABI uygulaması doğal seçimler
  C bağımlılıkları olan Rust projelerinde güvenlik garantileri zayıflıyor; yalnızca saf Rust kullanmak da mümkün ama zahmetli
  Rust da C bağımlılıklarını güvenli biçimde derleyip Rust ile bağlayabilmek için Fil-C ABI’yi uygulamalı; bunun neden tartışmalı olduğunu anlamıyorum

  • Rust’ta, güvenli olmayan Rust kodunun güvenli Rust’ın garantilerini koruyup korumadığını denetleyen Miri yorumlayıcısı zaten var
    Benzer bir işlev uygulanacaksa, yalnızca debug derlemelerinde FFI kodunu iyileştiren yardımcı bir araç olarak kullanılmasını isterim
    Çöp toplayıcı koyup tüm işlemleri çalışma zamanında denetleme yaklaşımı her kullanım alanına uygun değil

• Fil-C’yi basit yardımcı araçlar için bir şey diye geçiştirmeden önce Software Should Work konferansındaki Fil-C sunumunu izlemek gerekiyor
  Sunumu yapan kişi, kullanıcı alanının tamamı ve OpenOffice Impress bile Fil-C ile oluşturulmuş bir Linux dizüstüyle sunum yaptı
  Bazı C/C++ programları için uygun olmayabilir, ama yazarın düşündüğü kadar oyuncak bir teknoloji gibi görünmüyor

• Python kökenli olduğum için bellek güvenliği zaten temel varsayımdı; Rust’ı seçmemin üç nedeni vardı
  Birincisi, güçlü tip sistemiyle derleme zamanında doğruluğu sağlayabilmesi; #![forbid(unsafe_code)] ve cargo-geiger ile bağımlılık denetimi sayesinde elde edilen bellek güvenliği bunun en az ilginç ifadesi
  İkincisi, kodu bir kez güvenli yazıp birçok dil ve çalışma ortamında paylaşmayı kolaylaştıran bir ekosistem sunması
  Üçüncüsü, o dönemdeki try!(x) gibi üst düzey kod yazmayı rahatlatan sözdizimsel şekerlere sahip olması
  Zig ve Fil-C, tip durumu deseni veya yeni tipler gibi yollarla değişmez koşulları tip sistemine kodlayıp mantıksal hataları derleyicinin yakalamasını sağlama yeteneğini karşılamıyor gibi görünüyor
  Fil-C’nin ABI uyumsuzluğu da paylaşımlı web barındırmadaki CPython gibi mevcut çalışma zamanları için güvenli derlenen modüller yazarken sorun oluyor

  • Zig’de de tip durumu deseni ve çeşitli kısıtların tipe kodlanması mümkün; bazı açılardan comptime Rust’tan daha ifade gücü yüksek
    Derleme süresi, laf kalabalığı ve ekosistemin çoğunun bu seviyeye kadar denememesi gibi ödünleşimler var, ama gerçekten mümkün ve oldukça eğlenceli

• Fil-C gibi teknolojilerin neden 20 yıl önce ortaya çıkmadığını merak ediyorum

  • Mainframe alanında, işaretçileri ve yetenek tabanlı yetkileri paylaşma ve etiketleme yaklaşımının güvenlik sorunları onlarca yıldır uyarılıyordu
    Ama kimse CPU ya da bellek, yani maliyet tarafında bunun bedelini ödemek istemedi
  • Birkaç ay önce Filip’e benzer bir soru sordum ve şu yanıtı aldım
    2004–2018 arasında fikirler vardı, ama bellek güvenli C fikrinin kendisi aptalca görülüyordu; 2018–2023 arasında fikrini değiştirdi ama aşırı uyumluluğu sağlayacak yolu bulamadı
    2023–2024’teki ilk Fil-C’nin uyumluluğu ve performansı çok daha düşüktü; 2024 sonlarında InvisiCaps atılımı sayesinde bugünkü yüksek uyumluluk ve makul performans elde edildi
    2018 civarında fikrini değiştirmesinin tetikleyicisi, GPU’larda kullanılan C türevlerinin bellek güvenli C’nin basit biçimleri olduğu gözlemiydi
  • 20 yıl önce bilgisayarlar daha yavaştı ve güvenlik maliyetine çok daha duyarlıydı

• “Rust tarafı gerçekten bellek güvenliğine önem veriyorsa daha güvenli Fil-C’yi desteklemeli ve Rust’ı bırakmalı” sözünü en iyi niyetle yorumlarsak, artık Fil-C olduğuna göre dünyayı Rust ile yeniden yazma çabasını bırakıp C/C++’a dönerek eskisi gibi bütünleşik kütüphane ekosistemini koruyalım demek
  Rust kütüphaneleri C/C++’tan kullanılabilse de bunu istemeyen geliştiriciler olduğundan, Rust kullanıcıları daha iyi çözümü kabul edip vazgeçerse parçalanmanın ortadan kalkacağı mantığına dayanıyor
  Ancak Fil-C’de Rust’ta olmayan çöp toplayıcı ve yalnızca x86-64 Linux desteği gibi ödünleşimler var
  Bellek güvenliği dışında Cargo ve küresel ad alanının olmaması da Rust kullanmak için önemli nedenler; dil kampları arasındaki ayrışmanın daha geniş bir kültür savaşıyla iç içe geçmiş olması üzücü
  Sadece herkesin gönül rahatlığıyla kullanacağı kütüphaneler yapmak istiyorum

  • C ve C++’ın kendisiyle bile zaten parçalanmış bir ekosistem yok mu diye düşünüyorum
    C geliştiricileri arasında C++ kütüphaneleri istemeyenler olabilir; Zig ve Odin de ortaya çıktığına göre Rust kaybolsa bile parçalanma kalır
    Rust’ın özellikle farklı türde bir parçalanma mı yarattığını merak ediyorum
  • Ben de herkesin memnuniyetle kütüphane kullandığı bir dünya istiyorum ve jenerikleri comptime ile koruyan Rust→Zig yüksek seviyeli transpilatör üzerinde çalışıyorum
    Rust daha fazla kısıtı kodladığı için kaynak dil olarak ideal