Mungkin sudah saatnya meninjau ulang mikrokernel di era perangkat keras modern

• Mikrokernel yang dulu kurang praktis karena overhead tinggi, kini bisa kembali menjadi opsi realistis berkat IOMMU dan memori bersama yang sudah umum digunakan saat ini
• Dengan mengisolasi driver dan subsistem ke ruang pengguna, cakupan dampak dari cacat atau serangan dapat dibatasi sehingga meningkatkan keamanan, keandalan, dan modularitas
• Pada 1980-an hingga 1990-an, proses ruang pengguna tidak bisa mengakses perangkat secara langsung, sehingga untuk setiap operasi seperti membaca disk selalu ada system call dan context switch, penguncian, serta penyalinan memori
• Dengan memanfaatkan IOMMU dan antrean perintah bersama, IPC asinkron dan akses perangkat dapat ditangani tanpa context switch, penyalinan antar ruang alamat, atau penguncian pada jalur normal
• Karena dapat memanfaatkan komponen yang sudah ada seperti Xen, FreeBSD, dan Linux DRM, beban untuk membangun hypervisor dan server sistem dari nol juga tidak terlalu besar

---

Struktur mikrokernel dan efek isolasinya

• Mikrokernel adalah struktur kernel yang menjalankan fungsi selain penjadwalan, pengelolaan akses perangkat I/O, dan komunikasi antarproses (IPC) di ruang pengguna
• Isolasi subsistem memberikan tiga keuntungan
  • Keamanan: kerentanan pada satu driver tidak harus memberi penyerang akses ke seluruh sistem, melainkan hanya ke subsistem atau driver tersebut
  • Keandalan: crash pada satu subsistem hanya memengaruhi bagian itu, bukan seluruh sistem
  • Modularitas: mengurangi beban tim kernel Linux untuk menggabungkan semua driver perangkat keras dan meninjau hingga cara kerja internal setiap chip
• Jika Windows adalah sistem mikrokernel, bug CrowdStrike mungkin hanya akan menghentikan pengumpulan data telemetri bagi sebagian petugas keamanan TI dari jarak jauh

Batas performa di masa lalu dan solusi dari IOMMU

• Pada mikrokernel lama, proses ruang pengguna tidak bisa mengakses perangkat tertentu secara langsung sehingga setiap pekerjaan memerlukan system call dan context switch, diikuti penguncian yang mahal serta penyalinan memori
  • Mach secara bertahap memindahkan proses ruang pengguna kembali ke dalam kernel karena masalah performa, dan akhirnya menjadi mendekati kernel monolitik biasa
• Saat ini, PC selama sekitar 10 tahun terakhir telah secara standar dilengkapi IOMMU, dan bila digunakan bersama memori bersama, pada jalur normal dengan inti CPU yang memadai context switch bisa dihilangkan sepenuhnya
  • Dengan menerima sedikit latensi, secara keseluruhan pun context switch hampir bisa dihilangkan
  • Scheduler berbasis teknologi virtualisasi dapat disusun dengan bentuk yang mirip hypervisor Xen
  • Akses perangkat I/O dikelola oleh perangkat keras IOMMU
• IPC dapat diimplementasikan dengan cara mengalokasikan buffer bersama antarproses dan menyediakan compare-and-swap atomik bilangan bulat
  • Buffer bersama digunakan sebagai antrean perintah berbentuk ring buffer, lalu pointer awal dan akhir diperbarui secara atomik
  • Pada jalur normal, pesan asinkron dapat dikirim tanpa context switch, penyalinan antar ruang alamat, atau penguncian, dan metode ini juga banyak digunakan pada driver GPU

Susunan library dan pemanfaatan kode yang sudah ada

• Dalam lingkungan tempat proses menjadi guest VM, shared library dapat ditautkan saat program dimulai, dan fungsi yang tidak perlu dijalankan di proses lain dapat ditangani secara lokal dengan pendekatan exokernel
  • Di masa kini, ketika aplikasi sering didistribusikan bersama komponen sistem operasinya sendiri ala Electron, duplikasi library di memori tidak lagi menjadi masalah sebesar 30 tahun lalu
• Fondasi utama yang dibutuhkan untuk implementasi juga sudah ada
  • Xen memiliki sebagian besar fungsi yang diperlukan di lapisan hypervisor
  • Seperti Mach, server jaringan dan filesystem dapat disusun sambil memanfaatkan kode FreeBSD
  • DRM sudah berbasis buffer perintah asinkron, sehingga subsistem grafis Linux dapat dijalankan di ruang pengguna
  • Demi kepraktisan, server display dan subsistem grafis juga bisa dijalankan dalam proses yang sama

[GN⁺]

Komentar Lobste.rs

• Alasan Linux menyertakan semua driver adalah karena tidak ada API yang stabil untuk modul kernel di luar tree, dan mikrokernel bukan syarat wajib untuk menyediakan API semacam itu

  • Mikrokernel juga tidak mencegah ketidakstabilan API internal, hanya memindahkannya melintasi batas antarproses
    Saya ingat pernah melihat keluhan di LKML bahwa bahkan jika semua driver Linux dipindahkan ke user space, perubahan API internal tetap akan menjadi lebih sulit

• Seingat saya, kernel keluarga L4 dikenal cepat. Saya juga penasaran bagaimana dengan Redox OS atau Fuchsia

  • Kernel L4 mungkin bisa cepat, tetapi dalam praktiknya hanya cocok untuk sistem embedded yang konfigurasinya sangat tetap
    Genode mendukung beberapa kernel, tetapi pada seL4 dan semacamnya performanya sangat buruk sampai terasa konyol. Saat rekan-rekan mencoba menyalakan Linux VM, hanya 32-bit yang didukung, dan bahkan untuk boot setengah jalan saja butuh beberapa menit
    Ada alasan mengapa fork Genode dari NOVA microhypervisor menjadi platform default: itu benar-benar berjalan dan performanya juga cukup baik
  • Melihat dokumentasi Redox, saat merakit pesan permintaan mereka masih melakukan context switch, dan tampaknya itu untuk tahap verifikasi
    Karena menggunakan ring buffer, jika penerima sudah berjalan di core lain, context switch kedua mungkin tidak diperlukan. Jika pesan ditafsirkan tanpa context switch, penerima harus memverifikasi pesan itu sehingga permukaan serangannya bisa menjadi terlalu besar, meski tampaknya masih ada ruang untuk mitigasi lewat dynamic library yang disediakan kernel
    Saya bukan ahli, tetapi terasa seperti tulisan aslinya melewatkan beberapa pertimbangan penting

• QNX dikenal sebagai mikrokernel yang cepat, jadi saya penasaran apa yang mereka lakukan dengan benar

  • Dari pengalaman langsung, QNX tidak cepat
    Dulu saya dan seorang teman terpikat oleh keanggunan mikrokernel, khususnya QNX, lalu mengimplementasikan masalah pemrosesan video berbasis FireWire. Kodenya sederhana dan indah, tetapi sangat lambat. Saat itu saya menambahkan dukungan transmisi isokron berbasis DMA ke driver 1394 untuk Linux dalam sekitar 12 jam, dan performanya meningkat drastis; sejak kejadian itu, skeptisisme terhadap penggunaan Linux pada peralatan sortasi optik di perusahaan pun hilang
    Idealisme QNX, mikrokernel, dan message passing tetap luar biasa, tetapi agar bisa diterima luas, biaya pemindahan data antarproses harus ditekan jauh lebih rendah
    Sekarang saya membuat aplikasi web dengan Elixir dan menikmati isolasi proses seperti yang dijanjikan QNX. Karena ini bukan pekerjaan sensitif performa seperti pemrosesan optik, tidak masalah, tetapi Elixir/BEAM juga punya persoalan penyalinan data yang sama

• Walaupun Mach tidak berhasil memisahkan komponen sepenuhnya seperti dalam rancangan awalnya, saya dengar ia juga tidak menjadi kernel monolitik biasa, dan arsitekturnya masih memberi keuntungan tertentu
  Dalam benchmark daftar file POSIX klasik, seperti memanggil readdir() dan stat() pada setiap entri, mikrokernel pasti berada di posisi yang kurang menguntungkan. Namun jika frekuensi system call diturunkan dengan API pemrosesan batch seperti io_uring, latensi tinggi mungkin bukan kelemahan sebesar itu

  • Dalam “on μ-Kernel Construction”, 1995, Liedtke menyimpulkan bahwa penyebab Mach lambat adalah penggunaan cache yang besar, yakni desain yang tidak cukup kecil
    Linux juga tidak bisa mengikuti kecepatan jalur jika harus melakukan satu system call untuk setiap paket jaringan. Pemrosesan batch penting baik di Linux maupun mikrokernel

• Ada pendatang baru yang menarik di bidang ini, HongMeng, tetapi sayangnya ini perangkat lunak proprietari

• Kecuali biaya perpindahan data turun lebih dari satu orde besaran, mikrokernel tampaknya sulit menjadi cukup kompetitif
  Secara teori ia elegan dan rapi, tetapi kenyataannya rumit, jadi mungkin kernel juga harus cukup rumit untuk menangani kerumitan itu

• Saya menyukai arsitektur yang benar, tetapi menurut saya dominasi Linux juga sangat dipengaruhi faktor sekunder di luar teknologi murni. Saya ingin membaca tulisan yang menganalisis hal itu dari berbagai sisi