Modern Donanım Çağında Mikrokernelleri Yeniden Gözden Geçirmemiz Gerekebilir

 (notes.hella.cheap)
1 puan yazan GN⁺ 2 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Geçmişte yüksek ek yük nedeniyle pratikliği düşük olan mikrokerneller, bugün yaygınlaşan IOMMU ve paylaşımlı bellek sayesinde yeniden gerçekçi bir seçenek haline gelebilir
  • Sürücüleri ve alt sistemleri kullanıcı alanında izole etmek, hata veya saldırıların etki alanını sınırlayarak güvenlik, güvenilirlik ve modülerliği artırabilir
  • 1980'ler ve 90'larda kullanıcı alanı süreçleri aygıtlara doğrudan erişemediği için, disk okuma gibi her işlemde sistem çağrıları ve bağlam değişimleri, kilitler ve bellek kopyaları gerekiyordu
  • IOMMU ve paylaşımlı komut kuyrukları kullanılırsa, normal yolda bağlam değişimi, adres alanları arası kopyalama ve kilitler olmadan asenkron IPC ve aygıt erişimi gerçekleştirilebilir
  • Xen, FreeBSD ve Linux DRM gibi mevcut bileşenlerden yararlanılabildiği için hipervizör ve sistem sunucularını sıfırdan yazma yükü de büyük değil

Mikrokernel yapısı ve izolasyonun etkileri

  • Mikrokernel, zamanlama, I/O aygıt erişim yönetimi ve süreçler arası iletişim (IPC) dışındaki işlevleri kullanıcı alanında çalıştıran bir çekirdek mimarisidir
  • Alt sistem izolasyonu üç avantaj sağlar
    • Güvenlik: Tek bir sürücüdeki açık, saldırgana tüm sistem yerine yalnızca ilgili alt sistem veya sürücünün erişim yetkilerini kazandırabilir
    • Güvenilirlik: Bir alt sistemin çökmesi tüm sistem yerine yalnızca o bölümü etkiler
    • Modülerlik: Linux çekirdek ekibinin tüm donanım sürücülerini birleştirme ve her çipin iç işleyişini inceleme yükünü azaltabilir
  • Windows bir mikrokernel sistemi olsaydı, CrowdStrike hatası yalnızca bazı BT güvenlik sorumlularının telemetri veri toplamasını durdurmakla sınırlı kalabilirdi

Geçmişteki performans sınırları ve IOMMU çözümü

  • Eski mikrokernellerde kullanıcı alanı süreçleri belirli aygıtlara doğrudan erişemediği için her işlemde sistem çağrıları ve bağlam değişimleri gerekiyordu; buna pahalı kilitler ve bellek kopyaları da ekleniyordu
    • Mach, performans sorunları nedeniyle kullanıcı alanı süreçlerini giderek çekirdeğin içine taşıdı ve sonunda tipik bir monolitik çekirdeğe yaklaştı
  • Günümüz PC'lerinde IOMMU yaklaşık 10 yıldır standart olarak bulunuyor ve paylaşımlı bellekle birlikte kullanıldığında, yeterli çekirdek varsa normal yolda bağlam değişimini tamamen ortadan kaldırabilir
    • Bir miktar gecikme kabul edilirse, genel olarak da bağlam değişimleri neredeyse tamamen ortadan kaldırılabilir
    • Sanallaştırma teknolojisine dayalı bir zamanlayıcı, Xen hipervizörüne benzer bir yapıda kurulabilir
    • I/O aygıt erişimi IOMMU donanımı tarafından yönetilir
  • IPC, süreçler arasında paylaşımlı tamponlar tahsis edilip tamsayı atomik compare-and-swap sağlanarak uygulanabilir
    • Paylaşımlı tampon, halka tampon biçiminde bir komut kuyruğu olarak kullanılır ve başlangıç/bitiş işaretçileri atomik olarak güncellenir
    • Normal yolda bağlam değişimi, adres alanları arası kopyalama ve kilitler olmadan asenkron mesaj iletimi mümkündür; bu yöntem GPU sürücülerinde de yaygın olarak kullanılır

Kütüphane yapısı ve mevcut kodun kullanımı

  • Süreçlerin VM guest olduğu bir ortamda, paylaşımlı kütüphaneler program başlangıcında bağlanabilir ve başka süreçlerde çalıştırılması gerekmeyen işlevler exokernel yaklaşımıyla yerelde işlenebilir
    • Günümüzde Electron benzeri yapılarla her uygulamanın kendi işletim sistemi bileşenlerini birlikte dağıttığı dünyada, bellekteki yinelenen kütüphaneler 30 yıl önceki kadar büyük bir sorun değil
  • Uygulama için gereken temel yapı taşlarının çoğu zaten mevcut
    • Xen, hipervizör katmanı için gereken işlevlerin çoğunu zaten sağlıyor
    • Mach'taki gibi ağ ve dosya sistemi sunucuları kurulabilir; bunun için FreeBSD kodu alınarak kullanılabilir
    • DRM zaten asenkron komut tamponlarına dayandığı için Linux grafik alt sistemi kullanıcı alanında çalıştırılabilir
    • Kolaylık adına ekran sunucusu ve grafik alt sistemi aynı süreçte çalıştırılabilir

İlgili okumalar

1 yorum

 
GN⁺ 2 시간 전
Lobste.rs yorumları

  • Linux’un tüm sürücüleri içermesinin nedeni, ağaç dışı kernel modülleri için kararlı bir API olmaması; böyle bir API sağlamak için mikroçekirdek şart değil

    • Mikroçekirdekler de iç API’lerin kararsızlığını engellemez; sadece süreçler arası sınırların aşılması gerekir
      Tüm Linux sürücülerinin kullanıcı alanına taşındığı varsayımında bile, iç API değişikliklerinin zorlaşacağına dair LKML’de şikâyetler gördüğümü hatırlıyorum

  • L4 ailesi çekirdeklerin hızlı olduğu bilinmiyor mu? Redox OS ya da Fuchsia’nın nasıl olduğunu da merak ediyorum

    • L4 kernel hızlı olabilir, ama pratikte ancak yapılandırması çok sabit olan gömülü sistemlerde işe yarar
      Genode birden fazla çekirdeği destekliyor, ancak seL4 gibi çekirdeklerde gülünç derecede kötü performans veriyor. İş arkadaşlarım Linux VM başlatmayı denediğinde yalnızca 32-bit destekleniyordu ve yarıya kadar açılması bile birkaç dakika sürmüştü
      NOVA microhypervisor için Genode fork’unun varsayılan platform olmasının nedeni, gerçekten çalışması ve performansının da yeterli olması
    • Redox belgelerine bakınca, istek mesajını oluştururken hâlâ context switch yapılıyor; muhtemelen doğrulama aşaması gibi görünüyor
      Dairesel tampon kullanıldığı için alıcı başka bir çekirdekte zaten çalışıyorsa ikinci context switch gerekmeyebilir. Mesajı context switch olmadan yorumlamak, alıcının mesajı doğrulamasını gerektireceğinden saldırı yüzeyini aşırı büyütebilir; ancak kernel tarafından sağlanan dinamik kütüphanelerle bunu hafifletme imkânı var gibi görünüyor
      Uzman değilim ama özgün metin birkaç önemli hususu atlamış gibi

  • QNX hızlı bir mikroçekirdek olarak biliniyor; neyi doğru yaptığını merak ediyorum

    • Doğrudan kullandığım QNX hızlı değildi
      Eskiden bir arkadaşımla mikroçekirdeklerin, özellikle de QNX’in zarafetine kapılıp FireWire tabanlı bir görüntü işleme problemini uygulamıştık. Kod basit ve güzeldi ama korkunç derecede yavaştı. O sırada Linux için 1394 sürücüsüne DMA tabanlı eşzamanlı aktarım desteğini yaklaşık 12 saatte ekleyince performans büyük ölçüde iyileşti; bu olay şirketin optik ayıklama ekipmanlarında Linux kullanmaya yönelik şüpheciliği de ortadan kaldırdı
      QNX’in, mikroçekirdeklerin ve mesaj geçirme idealinin hâlâ harika olduğunu düşünüyorum; ancak yaygınlaşmaları için süreçler arası veri aktarma maliyetinin çok daha düşük olması gerekiyor
      Şimdi Elixir ile web uygulamaları geliştiriyorum ve QNX’in öne çıkardığına benzer süreç izolasyonundan yararlanıyorum. Optik işleme gibi performansın kritik olduğu bir iş olmadığı için sorun değil, ama Elixir/BEAM’de de veri kopyalama problemi aynı

  • Mach, başlangıçta tasarlandığı kadar bileşenleri tamamen bağımsızlaştıramamış olsa da sıradan bir monolitik kernel hâline gelmedi; mimarisinin hâlâ sağladığı avantajlar olduğunu duydum
    Klasik POSIX dosya listeleme benchmark’ında olduğu gibi her öğe için readdir() ve stat() çağrılırsa mikroçekirdeğin dezavantajlı olması kaçınılmaz. Ancak io_uring gibi toplu işleme API’leri kullanılarak sistem çağrısı sıklığı azaltılırsa yüksek gecikme büyük bir zayıflık olmayabilir

    • Liedtke’nin “on μ-Kernel Construction”, 1995 makalesi, Mach’ın yavaşlığının nedenini büyük önbellek kullanımı, yani yeterince küçük olmayan tasarım olarak görüyordu
      Linux da her ağ paketi için bir sistem çağrısı yaparsa hat hızına yetişemez. Toplu işleme hem Linux hem de mikroçekirdekler için önemli

  • Bu alanda ilginç yeni oyunculardan biri HongMeng, ancak ne yazık ki özel mülk yazılım

  • Veri taşıma maliyeti bir mertebe ya da daha fazla ölçüde ciddi biçimde düşmedikçe mikroçekirdeklerin yeterince rekabetçi olması zor görünüyor
    Teoride zarif ve temizler, ama gerçek dünya karmaşık; bu karmaşıklıkla başa çıkmak için çekirdeğin de bir ölçüde karmaşık olması gerekebilir

  • Doğru mimariyi seviyorum, ancak Linux’un baskın konuma yükselmesinde saf teknik dışında ikincil etkenlerin de büyük rol oynadığını düşünüyorum. Bunu birden çok boyutta analiz eden bir yazı okumak isterim