Supponiamo che io voglia costruire un sistema operativo basato su un kernel inferiore nativo molto piccolo che funge da interprete / runtime di codice gestito e un kernel superiore più grande compilato in un linguaggio macchina non nativo (bytecode Java, CIL, ecc.). Esempi di sistemi operativi simili sarebbero Singolarità e Cosmo .
Quali insidie e sfide di sviluppo esistono scrivendo un sistema operativo con questo tipo di infrastruttura in contrasto con una soluzione puramente nativa?
Risposte:
A seconda della lingua, ci possono essere molte sfide di sviluppo:
Puntatori: se una lingua non ha puntatori, sarà una sfida svolgere compiti relativamente semplici. Ad esempio, è possibile utilizzare i puntatori per scrivere nella memoria VGA per la stampa sullo schermo. Tuttavia, in una lingua gestita, avrai bisogno di una sorta di "plug" (da C / C ++) per fare lo stesso.
Assembly: un sistema operativo ha sempre bisogno di un po 'di assembly. Lingue come C #, Java, ecc. Non funzionano così bene con esso, a differenza di C / C ++. In C o C ++ puoi anche avere un assembly inline che è molto, molto utile per molte attività. Ci sono MOLTI casi in cui è necessario (esempi in x86): caricamento di un GDT, caricamento di un IDT, abilitazione del paging, impostazione di IRQ, ecc.
Controllo: se stai usando qualcosa come Cosmos, non hai il pieno controllo. Cosmos è un micro-kernel ed essenzialmente "avvia il bootstrap" il tuo "kernel". Puoi implementare qualcosa di simile a Cosmos da zero se lo desideri, ma ciò può richiedere molto, molto tempo.
Overhead: con le lingue gestite, c'è MOLTO overhead rispetto a C o anche a C ++. Cose come Cosmos devono implementare molte cose prima che anche un kernel c # world ciao possa essere eseguito. In C sei pronto per partire, non è necessaria alcuna configurazione reale. In C ++, ci sono solo alcune cose che devono essere implementate per usare alcune delle funzionalità di C ++.
Strutture: in C / C ++ ci sono strutture che molte lingue gestite non hanno, e quindi, dovresti implementare un modo per avere qualcosa come una struttura. Ad esempio, se si desidera caricare un IDT (Interrupt Descriptor Table), in C / C ++, è possibile creare uno struct (con un attributo compresso) e caricarlo usando l'istruzione x86 ASM lidt . In una lingua gestita, questo è molto più difficile da fare ...
Le lingue gestite, per quanto riguarda la sintassi, sono più facili, tuttavia, per molte cose relative al sistema operativo molte volte non sono molto adatte. Ciò non significa che non possano essere utilizzati, tuttavia, si consiglia spesso qualcosa come C / C ++.
Ho sentito affermare (da un ricercatore che lavora su una tecnica di microkernel concorrente ) che si sa molto poco su come valutare la sicurezza di sistemi estendibili attraverso il codice gestito.
Il problema è che i tipi di bug che potrebbero causare una falla nella sicurezza sono molto diversi da quelli a cui sono abituati i ricercatori della sicurezza. In un microkernel tradizionale tutti i driver e le altre sottoparti del kernel sono isolati l'uno dall'altro eseguendoli in spazi di indirizzi diversi. In un microkernel in cui l'isolamento viene implementato attraverso il controllo del codice gestito, si evitano le enormi spese generali di commutazione degli spazi degli indirizzi ogni volta che è necessario utilizzare un servizio secondario, ma il compromesso è che ora valutare il meccanismo di isolamento è più difficile.
Qualsiasi parte particolare del kernel (diciamo un driver di dispositivo) scritta nella lingua gestita è sicura se e solo se il controllo del tipo dice che il driver è sicuro e il controllo del tipo non ha bug. Quindi il controllo del tipo fa parte del nucleo del kernel. In pratica sembra che i controllori di tipi siano considerevolmente più grandi e più complicati dei tradizionali core di microkernel. Ciò significa che la superficie di attacco è potenzialmente più grande.
Non so se le tradizionali tecniche di isolamento micro-kernel o le tecniche di isolamento basate su codice gestito siano realmente più o meno affidabili. C'è un problema di bootstrap qui: fino a quando le tecniche di isolamento del codice gestito non saranno ampiamente utilizzate, non sapremo con quale frequenza non sono sicure. Ma senza sapere quanto siano insicuri, è difficile implementarli in situazioni critiche per la sicurezza.