Ağ anahtarını öldüren suçlu kimdi? 'Hubris bug' hikâyesi

Hubris bug hikâyesi: Ağ anahtarını öldüren kimdi?

• Hubris nedir?

  • Hubris, derinlemesine gömülü sistemler için bir işletim sistemidir; klavyenin içi gibi bilgisayar olarak tanınmayan bilgisayarlar için tasarlanmıştır.
  • Oxide Rack'te büyük işlemcileri başlatmak için gereken tüm işleri yürütmek üzere geliştirildi.
  • Hubris oldukça sıra dışıdır; hikâyeyle ilgili kısım aşağıda açıklanır.

• Suç mahalli

  • Oxide'ın ağ anahtarı firmware'inden sorumlu çalışma arkadaşı Arjen Roodselaar, güç sıralaması ve saat yapılandırmasıyla ilgili değişiklikleri test ediyordu.
  • Küçük bir değişiklikten sonra anahtar birden açılmaz hâle geldi.
  • Firmware'in bazı bölümleri yanıt veriyordu, ancak güç besleme sırasından sorumlu kritik bölüm durmuştu.

• Kısıtlı RAM'den daha fazlasını çıkarmak

  • Hubris kullanan düşük maliyetli mikrodenetleyicilerde RAM ve flash son derece sınırlıdır.
  • Hubris, görev adı verilen ayrı ayrı derlenmiş birçok programdan oluşur; bu yüzden diğer işletim sistemlerine göre kaynak gereksinimi biraz daha yüksektir.
  • Çalışma arkadaşı Matt Keeter kısa süre önce sistemi daha akıllı hâle getirerek, mümkün olduğunca çok görevi yerleştirmek için birden fazla 2'nin kuvveti bölge kullanmaya çalıştı.

• Dumanı tüten silah

  • Arjen, Humility adlı Hubris hata ayıklayıcısını kullanarak arızalı ağ anahtarını inceledi.
  • humility tasks komutuyla işlemci üzerinde çalışan görevlerin listesini ve durum bilgilerini çıkardı.
  • Güç sıralamasından sorumlu görevin, bellek hatası nedeniyle 115 kez yeniden başlatıldığını keşfetti.

• Hubris IPC'de Rust borrow kavramını görevler arasına genişletmek

  • Hubris görevleri IPC üzerinden birbirlerine mesaj gönderebilir.
  • Mesajlar, işlev çağrılarına çok benzer şekilde görünür ve çalışır.
  • Bir görev belleği başka bir göreve borrow ettiğinde, gerçekte sahip olmadığı belleği borrow etmeye çalışmamalıdır.

• Özellikler saldırıya geçtiğinde

  • İki özellik birleşerek bir bug'a dönüşebilir.
  • Görev paketleme, build sistemi içinde fırsatçı biçimde çalışır.
  • Görev A'nın boyutu biraz değişirse, ilgisiz görev B'nin MPU bölge sınırlarının konumu kayabilir.

• Çağrı içeriden geliyor!

  • Bellek koruma algoritmasının değiştirilmesi gerekiyordu.
  • Borrow edilen belleğin MPU bölgesini aşmasına izin verilmeliydi.

• Hubris ile başarısız olmak

  • Sistem arızalandığında gerçekleşmeyen birçok şey vardı.
  • Bozulan ağ anahtarı 3 saat içinde düzeltilebildi.
  • Arıza yalıtımı, güvenli şekilde hata verme, güvenli paylaşımlı bellek, kernel-debugger ortak tasarımı, tasarım ve uygulamadaki sadelik ve ekibin yakın, hiyerarşik olmayan entegrasyonu yardımcı oldu.

GN⁺'un görüşü

• Bu yazı, Hubris adlı işletim sisteminde ortaya çıkan bir bug'ı bulup çözme süreci üzerinden, karmaşık sistemlerde bile sağlam yazılım tasarımının önemini gösteriyor.
• Bug'ın keşfedilmesi ve çözülmesi süreci, yazılım mühendisliğinde karmaşık problemleri çözmede ekip çalışmasının ve verimli hata ayıklama araçlarının önemini vurguluyor.
• Hubris gibi sistemler kullanılırken, sistem yalıtımı ve arıza yönetimi özelliklerinin ne kadar kritik olduğunu gösteriyor. Bu, sistemin kararlılığını ve bakım yapılabilirliğini büyük ölçüde artırabilir.
• Bu yazı ayrıca, güvenli bir programlama dili olan Rust kullanarak bellek güvenliğinin nasıl sağlanabileceğini ve bug'ların nasıl en aza indirilebileceğini gösteriyor. Rust kullanan sistemlerde bu tür bug'lar nadiren görülür; bu da Rust'ın bellek güvenliği garantilerinin pratikte ne kadar etkili olduğunu kanıtlıyor.
• Benzer işlevlere sahip diğer proje veya ürünler arasında seL4, FreeRTOS ve Zephyr bulunuyor; bunların her biri farklı amaç ve özelliklere sahip gömülü sistem işletim sistemleridir.
• Hubris gibi sistemleri benimserken bellek kısıtları, görev yönetimi ve IPC mekanizmasının tasarımı gibi etkenler dikkate alınmalıdır. Bu tür sistemleri seçmenin avantajları sağlam sistem tasarımı ve güvenli bellek yönetimidir; dezavantajları ise sistemin karmaşıklığı ve öğrenme eğrisi olabilir.

[GN⁺]

Hacker News görüşleri

• Hubris çekirdek kod incelemesi

  • Hubris’in çekirdek kodunu yarım saat kadar okudum; oldukça açık ve iyi yazılmış. Daha önce gördüğüm karmaşık makrolar, iki harfli değişken adları ve yetersiz yorumlara sahip C kodlarından çok farklı. Uyumadan önce okumalık bir şey olarak tavsiye ederim.

• İş ilanına övgü

  • Bu, gördüğüm en iyi iş ilanlarından biri. Kültür konusuna doğal bir geçiş yapıyor ve sonunda "işe alım yapıyoruz" diyor. Hatta uygulama seviyesinde çalışan geliştiricilerin bile anlayabileceği harika bir post-mortem. Şu anda Rust öğreniyorum, bu yüzden böyle içeriklere hazırlıklıydım. Ayrıca, koduna bolca yorum ekleyen başka birinin çalışmasını görmek her zaman keyifli.

• Kod incelemesi ve öneri

  • Kodla ilgili küçük bir not: Bu, belirli bir fonksiyonun ayrıntısından ziyade tüm yazarların uyması ve tüm okurların yararlanması gereken bir alan değişmezi (invariant) yorumu olduğu için, bunu TaskDesc::regions dokümantasyon metnine eklemek iyi olabilir.

• Hata ayıklama sürecine değerlendirme

  • Karmaşık bir problemi hata ayıklarken derinlikli bir analiz sunuyor ve sistemin geri kalanının kararlı kalmış olması, Oxide ekibinin yüksek kaliteli mühendislik yaptığının kanıtı. Bundan kişisel olarak ilham aldım ve iş yerimde benzer teknikleri uygulamayı planlıyorum.

• Oxide ekibinin kültürüne ilgi

  • Oxide’ın mühendislik ekibi kendi içine kapalı değil; açıklığı, merakı ve iletişimi teşvik eden, savunmacılığı, alan kapma davranışını ve gatekeeping’i bastıran bir kültüre sahip. Bu kültürü oluşturmak ve korumak için çaba harcadılar; bunu, başka organizasyonlarda ayrı ekipler denecek sınırların ötesine yatay biçimde örgütlenme şekillerinde görmek mümkün. Bu kültürü yaratma motivasyonları ve bunu hayata geçirme konusundaki somut ayrıntılar hakkında daha fazlasını öğrenmek isterim. Organizasyon içinde "açıklık, merak, iletişim"i teşvik etmenin dezavantajları olup olmadığını ve daha katı hiyerarşik bir sistemi tercih ettikleri durumlar bulunup bulunmadığını merak ediyorum. Organizasyon şemasının stratejik olarak belirlenmesi gerektiğini düşünüyorum ama bunun ödünleşimlerini pek bilmiyorum.

• İlgili bilgi bağlantısı

  • Ön bilgiler verilen bağlantı üzerinden bulunabilir.

• Hata ayıklarken ortaya çıkan sorunla empati

  • Hata ayıklama kodu ekleyince ortadan kaybolan rastgele çökmelerin en kötü tür çökmeler olduğuna katılıyorum.

• Donanım işleme üzerine öneri

  • Donanımı yazılımla doldurulan bir TLB gibi ele alarak 8’den fazla bölgenin desteklenebileceğini belirtiyor.

• Oxide’ın çalışmasına övgü

  • Oxide’ın yaptığı iş karşısında hayranlığını ifade ediyor.

• İşletim sistemi adına tepki

  • İşletim sistemine Hubris adının verilmiş olmasına şaşırdığını ve buna tepki verdiğini belirtiyor.