Misalkan saya ingin membangun sistem operasi berdasarkan kernel rendah asli asli yang sangat kecil yang bertindak sebagai penerjemah / runtime kode terkelola dan kernel atas yang lebih besar yang dikompilasi ke bahasa mesin yang bukan asli (Java bytecode, CIL, dll.). Contoh sistem operasi yang serupa adalah Singularity dan Cosmos .
Apa jebakan dan tantangan pengembangan yang ada menulis OS dengan infrastruktur semacam ini berbeda dengan solusi murni asli?
Jawaban:
Bergantung pada bahasanya, mungkin ada banyak tantangan pembangunan:
Pointer: Jika suatu bahasa tidak memiliki pointer, itu akan menjadi tantangan untuk melakukan tugas-tugas yang relatif mudah. Misalnya, Anda dapat menggunakan pointer untuk menulis ke memori VGA untuk mencetak ke layar. Namun, dalam bahasa yang dikelola, Anda akan memerlukan semacam "colokan" (dari C / C ++) untuk melakukan hal yang sama.
Majelis: Suatu OS selalu membutuhkan perakitan. Bahasa seperti C #, Java, dll. Tidak bekerja dengan baik dengannya, tidak seperti C / C ++. Dalam C atau C ++ Anda juga dapat memiliki inline assembly yang sangat, sangat berguna untuk banyak tugas. Ada banyak kasus di mana ini diperlukan (contoh dalam x86): memuat GDT, memuat IDT, mengaktifkan paging, mengatur IRQ, dll.
Kontrol: Jika Anda menggunakan sesuatu seperti Cosmos, Anda tidak memiliki kontrol penuh. Cosmos adalah mikro-kernel dan pada dasarnya "bootstraps" "kernel" Anda. Anda dapat mengimplementasikan sesuatu seperti Cosmos dari awal jika Anda benar-benar menginginkannya, namun itu bisa memakan waktu yang sangat lama.
Overhead: Dengan bahasa yang dikelola, ada BANYAK overhead dibandingkan dengan C atau bahkan C ++. Hal-hal seperti Cosmos perlu mengimplementasikan banyak hal sebelum bahkan kernel dunia C # hello dapat dijalankan. Di C, Anda siap untuk pergi, tidak perlu pengaturan nyata. Di C ++, hanya ada beberapa hal yang perlu diimplementasikan untuk menggunakan beberapa fitur C ++.
Struktur: Di C / C ++ ada struct yang tidak dimiliki oleh banyak bahasa yang dikelola, jadi Anda perlu mengimplementasikan beberapa cara untuk memiliki sesuatu seperti struct. Misalnya, jika Anda ingin memuat IDT (Interrupt Descriptor Table), di C / C ++, Anda dapat membuat struct (dengan atribut dikemas), dan beban itu menggunakan x86 ASM instruksi lidt . Dalam bahasa yang dikelola, ini jauh lebih sulit dilakukan ...
Bahasa yang dikelola, sintaksis, lebih mudah, namun, karena banyak hal terkait OS sering kali sangat tidak cocok. Itu tidak berarti mereka tidak dapat digunakan, namun, sesuatu seperti C / C ++ sering direkomendasikan.
Saya telah mendengarnya diklaim (oleh seorang peneliti yang bekerja pada teknik microkernel bersaing ) bahwa sangat sedikit yang diketahui tentang bagaimana mengevaluasi keamanan sistem yang dapat diperluas melalui kode yang dikelola.
Masalahnya adalah bahwa jenis bug yang dapat menyebabkan lubang keamanan sangat berbeda dari yang digunakan peneliti keamanan. Dalam microkernel tradisional, semua driver dan sub-bagian kernel lainnya diisolasi satu sama lain dengan menjalankannya di ruang alamat yang berbeda. Dalam sebuah microkernel di mana isolasi diimplementasikan melalui pengecekan jenis kode yang dikelola Anda menghindari overhead yang sangat besar dari ruang alamat switching setiap kali Anda perlu menggunakan sub-layanan, tetapi tradeoff adalah bahwa sekarang mengevaluasi mekanisme isolasi lebih sulit.
Setiap bagian tertentu dari kernel (katakanlah driver perangkat) yang ditulis dalam bahasa yang dikelola aman jika dan hanya jika pemeriksa tipe mengatakan driver itu aman dan pemeriksa tipe tidak memiliki bug. Jadi pemeriksa tipe adalah bagian dari inti kernel. Dalam praktiknya tampaknya checker tipe jauh lebih besar dan lebih rumit daripada core microkernel tradisional. Itu berarti bahwa permukaan serangan berpotensi lebih besar.
Saya tidak tahu apakah teknik isolasi mikro-kernel tradisional atau teknik isolasi berbasis kode dikelola benar-benar lebih atau kurang dapat diandalkan. Ada masalah bootstrap di sini: sampai teknik isolasi kode terkelola banyak digunakan, kita tidak akan tahu seberapa sering mereka tidak aman. Tetapi tanpa mengetahui seberapa tidak amannya mereka, sulit untuk menempatkan mereka dalam situasi yang kritis terhadap keamanan.