- Kernel baru yang kompatibel dengan Linux ABI dan ditulis dengan Rust, menerapkan arsitektur “framekernel” untuk menggabungkan keunggulan kernel monolitik dan mikrokernel
- Dengan mengenkapsulasi semua kode unsafe di dalam library yang terbatas, layanan kernel lainnya dirancang agar dapat dikembangkan dengan abstraksi Rust yang aman, sehingga keamanan memori dan struktur shared memory yang sederhana dapat dicapai sekaligus
- Perbedaannya dengan Rust OS yang sudah ada seperti RedLeaf, Tock, dan Rust for Linux adalah dukungan isolasi perangkat keras dan tujuan umum, ABI yang kompatibel dengan Linux, serta eksekusi ruang pengguna dalam berbagai bahasa
- Mendorong minimalisasi TCB (trusted computing base) dan verifikasi formal (menggunakan Verus), mendukung perangkat keras trusted execution environment seperti Intel TDX, dan juga menyediakan framework pengembangan OS seperti OSTD/OSDK secara terpisah
- Masih dalam tahap pengembangan awal; saat ini mendukung x86/RISC-V dan telah mengimplementasikan 206 system call, berfokus pada lingkungan Docker/container/cloud, namun juga sedang mencoba ekspansi desktop seperti X11/Xfce
What's Asterinas?
- Asterinas adalah proyek kernel baru yang kompatibel dengan Linux ABI dan dikembangkan dengan Rust
- Arsitektur “framekernel” dirancang dengan membatasi kode Rust unsafe (bagian yang tidak aman terhadap memori) ke library framework dan membungkusnya dengan API aman, sehingga seluruh layanan kernel lainnya dapat dikembangkan sepenuhnya dengan Rust yang aman
- Menargetkan pencapaian sekaligus struktur sederhana dan performa tinggi dari kernel monolitik, serta minimalisasi TCB (trusted computing base) dan keamanan dari mikrokernel
- Layanan di dalam kernel berjalan terpisah dalam ruang alamat yang sama, dan masing-masing layanan hanya dapat menggunakan sumber daya yang diberikan oleh library inti
Penjelasan arsitektur framekernel
- Konsep framekernel pertama kali diusulkan dalam paper "Framekernel: A Safe and Efficient Kernel Architecture via Rust-based Intra-kernel Privilege Separation"
- Kernel monolitik adalah struktur yang menempatkan semua kode dalam satu ruang alamat mode kernel, sedangkan mikrokernel hanya mengalokasikan ruang kernel untuk TCB minimal dan mendelegasikan sebagian besar fungsi ke layanan mode pengguna
- Framekernel mengenkapsulasi kode yang memerlukan fitur
unsafe Rust ke dalam library, sementara layanan kernel lainnya dikembangkan dengan abstraksi Rust yang aman terhadap memori
- Setiap layanan berjalan di dalam ruang alamat kernel, tetapi dibatasi agar hanya dapat mengakses sumber daya yang secara eksplisit disediakan oleh library
- Menjaga TCB tetap kecil membuat verifikasi formal (pembuktian matematis) lebih mudah dilakukan, dan dapat meningkatkan keandalan serta stabilitas seluruh sistem
- Ini adalah pendekatan yang menggabungkan shared memory sebagai dasar (berperforma tinggi seperti kernel monolitik) sekaligus pemisahan hak akses internal/keamanan (keunggulan mikrokernel)
Perbandingan dengan Rust OS dan framekernel yang sudah ada
- RedLeaf: mikrokernel berbasis Rust, tidak menggunakan isolasi perangkat keras
- Asterinas: OS tujuan umum, memanfaatkan isolasi perangkat keras, kompatibel dengan Linux ABI, mendukung eksekusi ruang pengguna dalam berbagai bahasa
- Tock: menargetkan SoC embedded, memiliki struktur pemisahan antara inti (mengizinkan unsafe) dan kapsul (kode aman), tidak mendukung isolasi perangkat keras
- Proyek Rust for Linux juga bertujuan membungkus antarmuka kernel dengan abstraksi aman agar kernel driver dapat ditulis dengan Rust secara aman
Verifikasi formal dan keamanan
- Tujuan utama pengurangan TCB adalah agar verifikasi formal secara realistis menjadi mungkin
- Asterinas adalah satu-satunya kasus yang menargetkan sekaligus TCB kecil dan dapat diverifikasi seperti seL4, kompatibilitas Linux ABI, dan struktur shared memory
- Bekerja sama dengan perusahaan audit keamanan CertiK untuk melakukan verifikasi formal berbasis Verus
- Laporan evaluasi keamanan dari CertiK mengungkap titik audit proyek dan isu yang ditemukan
Library dan alat pengembangan
- Selain kernel itu sendiri, juga menyediakan OSTD (framework Rust OS) dan OSDK (alat pengembangan berbasis Cargo)
- Tujuan utama OSTD:
- Menurunkan hambatan masuk untuk pengembangan OS dan membangun landasan inovasi
- Memperkuat keamanan memori sistem operasi Rust dan abstraksi API level rendah
- Mendorong penggunaan ulang kode antarproyek Rust OS
- Memungkinkan pengujian kode baru di user mode (meningkatkan produktivitas pengembangan)
- Kernel berbasis OSD dan OSTD tidak harus kompatibel dengan Linux, dan menyediakan API tingkat tinggi yang aman terhadap memori untuk kontrol perangkat keras x86, memori virtual, multiprocessing (SMP), timer, dan lain-lain
- Intel ikut sebagai sponsor, terutama karena kecocokan dengan Trust Domain Extensions (TDX) dan teknologi terkait isolasi virtual machine
Status pengembangan dan sponsor utama
- Pertama kali dirilis sebagai open source (lisensi MPL) pada awal 2024, saat ini memiliki 45 kontributor; kontributor utama berasal dari mahasiswa doktoral di SUSTech, Peking University, Fudan University, dan Ant Group di Tiongkok
- Mendukung x86 dan RISC-V, serta telah mengimplementasikan 206 Linux system call (dari total 368)
- Masih belum dapat menjalankan aplikasi, menargetkan pengembangan distribusi awal dan dukungan container (Docker), serta sedang mencoba distribusi berbasis Nix
- Tidak mendukung pemuatan Linux kernel module dan tidak ada rencana untuk mengadopsinya secara permanen
Rencana ke depan
- Menetapkan dukungan untuk lebih banyak arsitektur CPU dan perangkat keras serta kegunaan nyata di lingkungan cloud sebagai prioritas jangka pendek
- Dukungan untuk perangkat Linux virtio telah selesai, dan pasar cloud Tiongkok (Alibaba Cloud, Aliyun) dijadikan target utama
- Tujuan utamanya adalah mengembangkan host OS untuk container dengan TCB yang aman dan diperkecil, serta dukungan untuk fitur trusted computing Intel
- Meski tujuannya mirip dengan Rust for Linux, Rust for Linux terbatas pada penulisan ulang driver di dalam kernel yang sudah ada dengan Rust, sedangkan Asterinas mengejar desain kernel baru secara menyeluruh dan minimalisasi TCB
- Saat ini juga sedang bereksperimen ke berbagai arah seperti dukungan X11 dan Xfce, dan OSTD sendiri memiliki potensi menarik perhatian pengembang OS umum
Perbedaan dengan Rust for Linux
- Rust for Linux: hanya memperkenalkan driver aman berbasis Rust ke kernel Linux yang sudah ada, sementara keseluruhan kernel tetap berbasis C
- Asterinas: mengimplementasikan kernel baru dari nol dengan Rust, membatasi
unsafe secara ketat, mendorong verifikasi formal, dan berfokus pada lingkungan cloud/container
Ringkasan dan prospek
- Asterinas sedang mencoba pendekatan inovatif dalam keamanan memori, verifikasi formal, dan kepraktisan untuk lingkungan cloud
- Masih belum ada contoh penggunaan nyata atau validasi komunitas yang luas, tetapi telah menarik perhatian di bidang riset OS, cloud, dan keamanan
- Framework seperti OSTD memiliki potensi untuk dimanfaatkan dalam ekosistem pengembangan Rust OS di masa depan
Ringkasan poin utama komentar LWN terkait Asterinas
- Perdebatan tentang Singularity OS dan batas keamanan berbasis bahasa
- Framekernel Asterinas mirip dengan Singularity OS dari Microsoft, tetapi memanfaatkan borrow checker Rust untuk meningkatkan keamanan memori
- Terkait pendekatan melindungi sistem dengan batas keamanan dari bahasa itu sendiri (misalnya Rust, Java, WASM/JS), ada perbedaan pendapat antara kritik bahwa "kepercayaan penuh itu mustahil dan pada praktiknya tetap harus dipakai bersama sandbox level hardware/OS" dan pandangan bahwa "pendekatan ini punya keunggulan dalam pencegahan cacat dan verifikasi formal"
- WASM, JS, dan Java juga memiliki perdebatan soal keamanan, tetapi dalam layanan nyata sandbox bahasa saja tidak dianggap cukup andal; pada praktiknya umumnya tetap digabungkan dengan sandbox hardware atau OS
- Tren pengembangan sistem operasi dan latar belakang geopolitik
- Dalam beberapa tahun terakhir berbagai proyek OS baru bermunculan, menunjukkan meluasnya atmosfer inovasi OS
- Tiongkok sedang mempercepat pengembangan OS alternatif Linux sebagai respons terhadap sanksi teknologi AS dan risiko rantai pasok
- Perdebatan tentang sanksi AS, GPL, tata kelola global open source, dan perlunya negara-negara seperti Tiongkok dan Eropa membangun ekosistem teknologi yang mandiri terus berlangsung sengit
- Tingkat kesulitan menjaga fork Linux dibanding mengembangkan kernel yang benar-benar baru, ketergantungan pada pengetahuan/know-how komunitas, dan hambatan bahasa juga menjadi topik perdebatan
- Perdebatan tentang kompatibilitas Linux/jumlah system call
- Banyak yang berpendapat bahwa "mengukur kompatibilitas dari jumlah Linux system call itu tidak tepat"
- Satu system call tunggal (
ioctl, dan sebagainya) dapat mencakup banyak API rinci, sehingga untuk kompatibilitas nyata, yang penting adalah menjalankan aplikasi sebenarnya atau kernel test suite
- Dengan mencontoh sejarah perkembangan Linux yang awalnya mengimplementasikan syscall satu per satu demi kompatibilitas POSIX, ada juga pendapat pragmatis bahwa jika 99% syscall utama didukung, cukup banyak software bisa dijalankan
- Lisensi dan ekosistem Rust
- Ada diskusi tentang pilihan Asterinas terhadap MPL: sebagian menilai MPL cocok dengan ekosistem crate Rust dan lisensi modular
- Ada pula pandangan bahwa GPL tidak selalu yang terbaik, dan jika mendapat dukungan perusahaan maka lisensi yang ramah perusahaan (seperti MPL) bisa dipilih
- Dependensi proyek/keamanan
- Muncul pertanyaan apakah aman menggunakan banyak crate eksternal dalam OS berbasis Rust, serta perlunya otomatisasi keamanan rantai pasok dan audit melalui cargo deny/vet dan semacamnya
- Disebut juga bahwa lockfile saja membuat sulit memahami permukaan dependensi, dan ada kompleksitas khas ekosistem Rust seperti dependensi transitif serta dependensi spesifik per-OS
- Inspirasi teknis/arsitektur serupa
- Disebutkan bahwa konsep framekernel mirip dengan arsitektur SPIN OS dari University of Washington pada era 1990-an
- SPIN juga menekankan modularitas yang kuat serta kontrol antarmuka/akses oleh compiler
- Kontroversi komposisi committer
- Disebutkan bahwa dari 45 kontributor, banyak commit berasal dari sejumlah kecil mahasiswa doktoral
- Ada pendapat yang menolak anggapan bahwa kontribusi yang dipimpin mahasiswa PhD kurang bernilai sebagai committer, dan menilai proyek ini tetap bermakna sebagai proyek inovasi berorientasi riset
- Perdebatan politik/sejarah dan penilaian off-topic
- Diskusi OS meluas ke perdebatan geopolitik, politik, dan sejarah antara AS, Eropa, dan Tiongkok, sehingga editor beberapa kali memberi peringatan "off-topic"
- Sejumlah pengguna menekankan bahwa ekosistem open source/FOSS juga bisa terpengaruh oleh perubahan lingkungan geopolitik
- Lain-lain
- Dibagikan paper akademik tentang keamanan WASM
- Terdapat campuran pandangan positif dan kritis terhadap status pengembangan kernel
2 komentar
Upaya seperti ini kelihatannya sangat bagus.
Mungkin tak lama lagi akan muncul kernel yang tidak mati.
Opini Hacker News
Menurut saya ini pendekatan yang menarik, dan saya berharap berhasil. Tapi saya masih ragu. Saya masih ingat apa yang pernah dikatakan Linus tentang pesaing dalam wawancara TV pada akhir 90-an atau awal 2000-an. Linus pernah mengatakan sesuatu seperti, "Tidak ada yang menikmati menulis driver, jadi kita aman sampai ada seseorang yang muda, lapar, dan muncul sebagai insinyur driver yang hebat." Bahkan saat itu pun dia sudah sadar bahwa menjaga antarmuka driver tetap tidak stabil adalah semacam mekanisme pertahanan. Sekarang 25 tahun telah berlalu, kernel yang berjalan di atas hardware virtualisasi sudah sangat umum, tetapi sistem operasi yang benar-benar praktis dan bisa dipakai, yang berhasil mengabstraksikan hardware nyata, tetap bisa dihitung dengan jari
Pada bagian "menjaga antarmuka driver tetap tidak stabil sebagai mekanisme pertahanan", saya merasa ke depannya mungkin akan muncul peneliti sistem yang muda dan lapar, atau AI, sehingga agen AI bisa menerjemahkan driver Linux berbasis C menjadi driver Asterinas berbasis Rust yang aman. Pendekatan realistis lain adalah mendaur ulang kernel Linux itu sendiri dengan menaruhnya di dalam suatu lingkungan isolasi. Misalnya, kernel HongMeng menggunakan User-Mode Linux untuk memakai ulang driver. Asterinas juga bisa menerapkan strategi serupa. Referensi: https://www.usenix.org/conference/osdi24/presentation/chen-haibo
Saya ragu Linus benar-benar menginginkan atau sengaja membuat "parit pertahanan" seperti itu. Dia bukan pendiri startup teknologi, awalnya hanya seorang kernel hacker, dan fondasi hidupnya sudah aman seumur hidup. Menafsirkan ketidakstabilan antarmuka driver di dalam kernel sebagai strategi sengaja untuk mencegah kompetisi terasa seperti proyeksi yang berlebihan
Sebelumnya juga sudah ada preseden seperti SPIN OS (Modula 3), JX OS (Java), House OS (Haskell), dan Verve. Semuanya mengimplementasikan fungsi kernel dengan bahasa yang type-safe dan memory-safe. Umumnya strukturnya menyembunyikan hal berbahaya di balik pemanggilan fungsi yang sudah diperiksa, sebagian juga memanfaatkan VM. Terlepas dari masalah performa atau adopsi, titik lemahnya biasanya adalah celah dalam abstraksi, bypass lewat kode unsafe, runtuhnya model safety akibat compiler/JIT, dan cacat hardware umum (misalnya cosmic ray di pesawat luar angkasa). Meski begitu, tetap jauh lebih aman dibanding kernel/aplikasi dengan bahasa unsafe. Untuk melangkah lebih jauh, bisa dilakukan analisis statis pada kode unsafe, menjamin semua fungsi unsafe mematuhi antarmuka yang type-memory-safe, memakai compiler yang mempertahankan keamanan abstraksi saat integrasi, dan bahkan compiler tersertifikasi per komponen. Kebanyakan alat produktivitasnya sudah ada; yang kurang hanya "kompilasi abstraksi yang sepenuhnya aman", yang saat ini masih diteliti, meski pemeriksaan manual juga memungkinkan
Ada alasan mengapa jumlah sistem operasi yang benar-benar bisa dipakai itu sedikit. Dunia hardware penuh dengan 'standar' antarmuka, tetapi hardware nyata hampir tidak pernah benar-benar bekerja sesuai standar. Tanpa waktu untuk menulis kode driver yang menangani berbagai keanehan dan cacat permanen yang tidak bisa diperbaiki (errata), sangat sulit mendapat performa dan dukungan di hardware fisik nyata
Di sisi lain, 98% Linux yang saya tangani memang berjalan di lingkungan virtualisasi. Di desktop/laptop saya menjalankan Virtualbox layar penuh, driver untuk Windows hanya dipakai kalau benar-benar perlu, dan di Mac saya pakai VM headless yang dikelola Docker.app. Semua workload operasional perusahaan berjalan di AWS VM. Satu-satunya hardware Linux yang saya pakai di rumah juga hanya home server, dan sebentar lagi akan diganti dengan Mac mini VM bekas dari eBay. Kalau ada kernel yang kompatibel dengan Linux tetapi lebih aman dan performanya mirip, sekarang ini rasanya mudah memilih alternatif meski drivernya kurang lengkap
Saya dengar belakangan ini microkernel sudah banyak memperbaiki isu performa IPC. Saya agak lupa seberapa besar peningkatannya, tetapi sepertinya trauma industri akibat Mach memang besar. Melihat situs proyeknya, justru strukturnya adalah hanya Framework (mode terprivilege) yang boleh memakai Rust unsafe, sementara Services (non-privilege) hanya memakai Rust aman. Rasanya agak janggal; kalau kode non-privilege memakai unsafe, bukankah itu tetap berbahaya meski non-privilege? Sebaliknya, kode unsafe yang justru benar-benar perlu diverifikasi malah boleh dipakai tanpa batas di sisi yang terprivilege? Dan kalau melihat lisensinya, Asterinas terutama memakai Mozilla Public License (MPL) 2.0, dengan sebagian komponen memakai lisensi yang lebih permisif. Rasanya berada di tengah-tengah, bukan GPL dan bukan juga BSD
Untuk pertanyaan "aneh kalau non-privilege yang unsafe juga berbahaya, sementara kode yang benar-benar perlu verifikasi justru dikumpulkan di sisi privilege", struktur ini harus dipahami dalam konteks framekernel. Seluruh framekernel berbasis Rust berjalan di kernel space, tetapi secara logis dibagi menjadi dua bagian: framework OS terprivilege dan service OS non-privilege. Bagian terprivilege mencakup kode kernel Rust safe maupun unsafe, sedangkan bagian non-privilege hanya mencakup kode kernel Rust safe. Kebijakan ini semuanya berlaku untuk kode kernel. Dalam framekernel, tidak ada pembatasan bahasa untuk program user
Setahu saya, microkernel modern kebanyakan memang sudah memperbaiki performa IPC secara dramatis. Contoh utamanya SeL4, yang mengoptimalkan IPC dengan sangat agresif, sampai-sampai IPC-nya jauh lebih cepat daripada syscall Linux pada umumnya. Banyak program kemungkinan justru berjalan lebih cepat di SeL4. Saya penasaran dengan data perbandingan performa yang nyata
Benar bahwa microkernel modern sudah memperbaiki isu IPC. Sebenarnya masalah yang lebih mendasar adalah pada hardware modern, bahkan syscall kernel monolitik pun sangat lambat. Itu sebabnya antarmuka seperti io_uring atau virtio bisa memberi performa bagus: sistem dan aplikasi (atau hypervisor dan guest) memproses permintaan dan respons lewat queue sehingga tidak perlu berpindah address space. Ke depan, sistem operasi dengan struktur apa pun akan membutuhkan mekanisme syscall berbasis 'queueing'. Dan jika pendekatan ini dipakai, perbedaan performa besar antara OS monolitik, microkernel, atau struktur lain pada dasarnya hilang
Dalam framekernel, pemisahan privileged/unprivileged bukan berarti kernel/userspace. Seluruh OS berjalan di level privilege kernel. Hanya saja, secara logis dibagi menjadi kode pustaka inti (boleh memakai unsafe, privileged) dan kode komponen kernel lainnya (memakai pustaka itu, tidak boleh langsung memakai unsafe, unprivileged). Mungkin ini ditegakkan lewat pemeriksaan statis seperti linter. Struktur ini mudah membingungkan karena istilahnya dipakai ganda
Task non-privilege juga berjalan dalam ruang memori yang sama dengan inti kernel, jadi tidak ada cara bagi runtime untuk mencegah perilaku tidak aman. Untuk benar-benar memisahkan privilege saat runtime, dibutuhkan struktur microkernel. Di sini privilege diterapkan bukan saat runtime, melainkan secara statis, yaitu dengan melarang kode unsafe
Saya penasaran apakah konsep memisahkan kernel menjadi inti unsafe yang kecil dan modul safe yang besar ini merupakan percobaan baru. Menarik dan menjanjikan karena proyek ini tampaknya memanfaatkan dengan baik sifat pemisahan safe/unsafe dalam bahasa sistem, tanpa overhead hardware microkernel dan sambil menghindari isu keamanan kernel monolitik
Ini mengingatkan saya pada tulisan ulasan Drew DeVault tentang Rust in Linux. Diskusi HN-nya juga bisa dihubungkan https://news.ycombinator.com/item?id=41404733
Menurut saya ini upaya yang benar-benar luar biasa, dan saya juga terkesan penulisnya hadir di thread ini. Saya penasaran sejauh mana tingkat usability-nya; saya ingin mencoba membangun image server dan bereksperimen, meski hanya di lingkungan terbatas
Saat melihat penjelasan bahwa microkernel IPC tidak populer karena lambat, saya merasa lega bahwa bahkan orang yang sangat ahli secara teknis pun tampaknya salah memahami alasan adopsi di dunia nyata dan prosesnya
Lisensinya MPL, dan secara pribadi saya rasa ada lisensi yang lebih baik (misalnya GPLv3)
Menurut saya ini ide yang sangat bagus. Sudah banyak software yang dibangun, dan punya fondasi alternatif bisa memberi keuntungan atau pilihan besar, bahkan karena alasan non-teknis. Ini mengingatkan saya pada kFreeBSD dan GNU/Hurd
Saya jadi berpikir, kernel seperti ini sebaiknya disebut apa. *nux?