Sunucunun Şiddet Seçimi

Hubris IPC'ye genel bakış

• Hubris, küçük ve uygulamaya bağımlı olmayan bir çekirdek kullanır; kodun büyük kısmı (sürücüler, uygulama mantığı, ağ yığını vb.) ise ayrı derlenmiş, yalıtılmış görevlerde bulunur
• Bu görevler, çapraz görev mesajlaşma sistemi (IPC) kullanarak birbiriyle iletişim kurabilir
• Hubris'in IPC'si, çekirdekte uygulanan 3 temel işlemden oluşur: RECV, SEND, REPLY
  • RECV: Gelen en yüksek öncelikli mesajı alır veya mesaj gelene kadar bloklanır
  • SEND: Mesajı ve denetimi alıcı göreve iletir ve çağıranı durdurur. Çağıran, yanıt alana kadar bekleme durumuna geçer
  • REPLY: Daha önce SEND kullanan göreve bir yanıt ileterek ilerlemeye devam etmesini sağlar

Yeni ve ilginç bir hata modu

• IPC, görev sınırlarını aştığı ve Hubris görevleri ayrı ayrı derlenmiş programlar olduğu için, derleyicinin bir fonksiyon çağrısında varsaydığı türden varsayımları IPC'de yaparken dikkatli olmak gerekir
• Hubris'te IPC sunucusu rolünü üstlenen tüm görevlerin şu olası hataları ele alması gerekir:
  • Arabirimle uyumsuz bir işlem koduna sahip mesaj alınması
  • Beklenen mesaj türü yerine yorumlanamayan bir bayt kümesi ya da çok kısa veya çok uzun bir mesaj alınması
  • Gerekli belleğin (örneğin yazılabilir bellek) sağlanmaması

Normal ve doğru programlarda bu durumlar ortaya çıkmaz

• Normal bir Hubris programında yukarıda belirtilen durumlar yaşanmaz
• Görevler, yapı sisteminin yapılandırmasıyla birbirine bağlandığı için birbirleriyle karıştırılmaları zordur
• İstemci ve sunucu, üretilmiş Rust kodunu kullandığından tür sisteminin görev sınırlarının ötesinde de çalıştığı varsayılabilir

Çekirdek hiçbir saçmalığa izin vermez

• Unix'te sistem çağrısının önkoşulları ihlal edilirse çağırana hata kodu döndürülür; Hubris'te ise görev anında yok edilir
• Hubris çekirdeği, Synthetic Fault kavramı üzerinden çekirdek kurallarını ihlal eden görevlere hata iletir
• Hubris'te donanım veya sentetik bir hata oluştuğunda görev anında durdurulur ve kurtarılamaz

Sunucu da hiçbir saçmalığa izin vermez

• REPLY_FAULT adlı 13. ve en sıra dışı sistem çağrısı aracılığıyla sunucu, istemciye hata iletebilir
• REPLY_FAULT, REPLY'ye benzer; ancak bir mesaj iletip görevi çalışabilir duruma getirmek yerine hata iletir ve görevi durdurur
• REPLY_FAULT sayesinde gereksiz IPC hata işleme mantığından kaçınılabilir. Normal programlar, sanki bir sorun çıkması mümkün değilmiş gibi çalışır; anormal programlar ise hatayı ele alma fırsatı bile bulamaz
• REPLY_FAULT, erişim denetimi kuralları gibi uygulamaya özgü hataları tanımlamak ve uygulamak için yeni bir yol sunar

GN⁺'un görüşü

• REPLY_FAULT, sunucunun istemci tarafının işbirliği olmadan istemcide süreçler arası bir panic! tetikleyebilmesini sağlayan güçlü bir mekanizmadır. Bu sayede Hubris, kötü niyetli programlara karşı son derece düşmanca bir sisteme dönüşür
• REPLY_FAULT'un dezavantajı, fuzzing testlerini çok zorlaştırmasıdır. Rastgele IPC ya da sistem çağrıları üreten kaos mühendisliği görevleri, neredeyse her davranışta anında sıfırlanır
• Ancak normal Hubris görevleri IPC mesajlarını dinamik olarak üretmediğinden, REPLY_FAULT'un varlığının farkına varmadan da çalışabilir
• REPLY_FAULT ile sunucu istemcide rastgele hata oluşturabilir; ancak bunun değerlendirmesi henüz tam olarak yapılmış değildir
• Hubris'in agresif hata işleme yaklaşımı, geliştirme sürecinin erken aşamalarında hataları bulmaya yardımcı olur ve hata kodlarından farklı olarak hataların göz ardı edilmesini engeller
• IPC hatalarını ele almak için evrensel bir yöntem kullanmak, normal programlarda da gereksiz ek yük yaratabilir. REPLY_FAULT, bundan kaçınırken anormal programlara karşı katı davranabilen zarif bir çözüm gibi görünüyor

[GN⁺]

Hacker News görüşü

Özetle şöyle deniyor:

• REPLY_FAULT'un zincirleme biçimde yayılıp yayılmadığı ve bunun doğuracağı güvenlik açıkları konusunda endişeler dile getiriliyor

  • A B'yi bekliyor, B de C'yi bekliyorsa ve C bir REPLY_FAULT üretirse A'nın da birlikte sonlanıp sonlanmadığının doğrulanması gerekiyor
  • Eğer öyleyse tüm sistem savunmasız hale gelebilir
  • SEND döngüsel bir yapıdaysa istemeden kendi kendini de sonlandırmak mümkün olabilir

• REPLY_FAULT, erişim kontrolü gibi uygulamaya özgü hataları tanımlayıp uygulamanın bir yolunu sunuyor

  • Bu, sistemin küçük ve sıkı bağlı olduğu, ayrıca uygulamaların çoğunu sistem tasarımcısının yazdığı durumlarda kullanışlıdır
  • Ancak üçüncü taraf kodlarla entegrasyonda, karşı tarafın süreci istediği anda anında sonlandırabilmesi endişe vericidir
  • Dünyada yöneticiler tarafından bunaltılmış geliştiricilerin yazdığı çok sayıda kötü sürücü ve arka plan süreci var

• Tüm kodun tek bir ekip tarafından yazıldığı sistemlerde, şüpheli istemcileri ayıklamak yineleme hızını artırabilir

• Hubris, sunucunun istemcinin başa çıkamayacağı etkileri gerçekleştirmesine izin veren bir çekirdek olarak görülebilir

  • Bu, kod yeniden kullanımını ve bileşimi zorlaştırır ama yürütme modelini basitleştirir
  • Statik gömülü sistemlerde doğru ödünleşim bu olabilir

• Hubris ve Humility, derinlemesine dalmak isteyeceğiniz teknolojiler, ancak zaman ve yükümlülükler buna engel oluyor

• HTTP için 1 Nisan şakası niteliğinde bir RFC olarak, "Kendinizden utanmalısınız" anlamına gelen HTTP 499 durum kodu öneriliyor

  • Bu, "Ne oluyor... ama aslında fena değil" gibi bir bağlama uyuyor

• Einstein'ın "Mümkün olduğunca basit, ama gereğinden fazla basit değil" sözü alıntılanarak Hubris'in tasarımının ikinci kısmı ihlal ettiği söyleniyor

  • Gerçek dünyanın dağınıklığına hiç izin vermeyen işletim ortamlarıyla ilgilenilmiyor

• Humility bir debugger adı olarak harika duruyor

  • Pek çok programcı, "iyi" kodun debug edilmesi gerekmediğini varsayıp debugger kullanmayı reddediyor

• Linux'ta yalnızca soketler aracılığıyla başka bir programı doğrudan sonlandırmak mümkün değildir, ancak root yetkisiyle başka süreçler sonlandırılabilir, hatta sistem yeniden başlatılabilir

  • Container ortamlarında root yetkisi yaygın olduğundan bu tür bir risk vardır

• "Kabul ederken esnek, gönderirken katı ol" şeklindeki yerleşik ağ sistemi bilgeliğiyle bir ölçüde çelişiyor

  • Ancak API değiştirirken mevcut programlarla uyumluluğu korumak için kabul tarafında esnek olmak kaçınılmaz olabilir