Quali sono le potenziali insidie ​​nell'avere un kernel minimo che esegue il codice gestito?


14

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:


8

A seconda della lingua, ci possono essere molte sfide di sviluppo:

  1. 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.

  2. 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.

  3. 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.

  4. 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 ++.

  5. 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 ++.


Questa risposta è piuttosto debole. Quali sono i "compiti relativamente facili" che non puoi fare a meno dei puntatori (escludendo una minuscola base)? Quali sono le parti che devono essere assemblate? Quale controllo ti manca? Su cosa basi la tua dichiarazione sull'overhead? Perché non puoi avere strutture in una lingua gestita?
Gilles 'SO- smetti di essere malvagio' il

1. Non vi è alcun motivo per cui un linguaggio gestito non offra la possibilità di accedere alla memoria VGA, è solo la mappatura / non mappatura che dovrebbe essere fornita come primitiva (una primitiva di gestione della memoria). 2. Alcune operazioni di commutazione (ad es. Salvataggio dei registri) devono essere generalmente eseguite come codice assembly, ma è molto localizzato, non è un argomento contro il 99% del sistema operativo in una lingua gestita. La manipolazione della MMU è una primitiva di gestione della memoria. 4. Anche C ha bisogno di essere installato (impostare uno stack e un heap); le lingue gestite necessitano di un po 'più di configurazione ma non ci sono differenze qualitative.
Gilles 'SO- smetti di essere malvagio' il

@Gilles, la domanda è quali sono le sfide dello sviluppo per l'utilizzo di un linguaggio gestito. Queste sono sfide di sviluppo, tuttavia, è ancora possibile superare con successo tali sfide ...
mmk

5

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.


Questo è un punto eccellente.
Adam Maras,

Trovo questi argomenti molto strani. (Certo, potrei essere distorto dal mio background nei metodi formali, ma questa non è l'unica base per la mia opinione.) Un typechecker non è così complesso, rispetto a un microkernel più una MMU. Ad esempio, il microkernel di Coq è circa 14kLoC di OCaml - più grande di un microkernel, ma non di molto, e scritto in un linguaggio che è meno soggetto a errori rispetto alla maggior parte dei kernel (no C o assemblatore). I controllori del tipo non sono sensibili alle condizioni di gara, che sono una classe di bug particolarmente sottile.
Gilles 'SO- smetti di essere malvagio' il

Il codice gestito offre una migliore opportunità per gestire determinate classi di bug; ad esempio, l'analisi del flusso di informazioni può dimostrare l'assenza di canali laterali (è probabile che ci vorrà molto lavoro e non so fino a che punto è stata eseguita, ma è fattibile in linea di principio), mentre l'isolamento hardware consente solo di testare i canali laterali a cui hai pensato.
Gilles 'SO- smetti di essere malvagio' il

Sul lato pratico, diverse macchine virtuali che forniscono isolamento sono state certificate da EAL5 e successive. Ecco due esempi che potresti avere nel tuo portafoglio se sei europeo, perché vengono utilizzati nelle smart card come le carte di credito: MULTOS , piattaforma aperta Java Card . Nella comunità di valutazione della sicurezza, ho sentito molti dubbi sul fatto che l'isolamento MMU potrebbe andare oltre EAL2.
Gilles 'SO- smetti di essere malvagio' il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.