Un kernel monolitico è più sicuro di un microkernel per un SO piccolo?

I microkernel sono generalmente considerati più sicuri non solo dal punto di vista teorico. Di solito le loro capacità sono più ristrette rispetto a quelle di un kernel monolitico "general purpose" e quindi contengono meno bug semplicemente perché il loro codebase è più piccolo. Viceversa, più codice esegui con privilegi elevati, migliori sono le tue possibilità di disastro.

Dal punto di vista teorico, ci sono diversi punti chiave per cui un microkernel è intrinsecamente più sicuro (purché sia implementato correttamente):

1. separazione dei driver dal kernel (e viceversa) - un driver audio / di rete mal riuscito / malevolo non può arrestarsi in modo anomalo o modificare in modo silenzioso il kernel (o un altro driver o applicazione utente). Uno dei cardini fondamentali di questa separazione è l'implementazione di IPC mediante il passaggio di messaggi anziché ad es. memoria condivisa, poiché consente al kernel di disinfettare i dati trasferiti. Lo stesso vale per i processi utente "regolari", ovviamente. È anche una delle più grandi penalità prestazionali rispetto ai kernel monolitici.

2. I driver che sono processi separati possono essere eseguiti in un diverso anello di protezione rispetto al microkernel e alle applicazioni che non richiedono qualsiasi accesso hardware. Questo deve essere supportato dall'hardware, naturalmente.

3. Leaner codebase consente la verifica formale di alcuni micro-kernel tra cui la correttezza end-to-end di seL4 (risultato removibile, se me lo chiedi). Pertanto, una specifica ben scritta può comportare risultati attesi solo . Questo rende l'addendum sull'implementazione sopra ridondante.

A parte questo, i microkernel sono anche più sicuri : un driver in errore può essere riavviato senza che il resto del sistema ne risenta (questo ovviamente impone alle applicazioni che utilizzano un driver un po 'resiliente ai guasti del driver). Ciò significa che un autista di un display non funzionante in un aereo passeggeri non solo non è in grado di far cadere l'intero sistema di controllo dell'aereo, ma non richiede nemmeno un riavvio completo che impiega diversi secondi (che non si hanno quando si atterra , decollo o volo in condizioni meteorologiche avverse). L'esempio classico può essere INTEGRITY (178B) - nota che (come molti kernel simili / sistemi) manca di cose come l'allocazione dinamica della memoria, che è solo una sorta di comfort a cui devi vivere senza se vuoi mettere dei vincoli come una dura esecuzione in tempo reale sul tuo sistema.

In teoria, un microkernel, inserendo la maggior parte del codice del driver nello spazio utente, è più resistente contro gli attacchi: un attacco contro un driver non può essere facilmente utilizzato per sfruttare l'accesso agli altri driver o ottenere il kernel privilegi. Inoltre, le dimensioni ridotte del kernel gli danno una superficie di attacco molto più piccola.

In pratica, l'architettura del kernel è solo un aspetto secondario della sicurezza. L'attenzione del progettista per la sicurezza e la qualità dell'attuazione hanno un impatto molto maggiore.