Primo, ad un certo livello si avrà sempre un componente che Can not Fail ™. Se questo componente si arresta in modo anomalo, non è possibile il ripristino. Ad esempio, se si esegue il cestino della tabella dei processi in esecuzione, non è possibile ricostruirlo a parte il riavvio. Quindi, anche con la protezione della memoria che limita gli arresti anomali di questo componente a influire solo su se stesso, possono verificarsi BSOD (o l'equivalente).
Ma il tuo punto è buono: ci sono un certo numero di componenti che spesso possono essere ripristinati senza un errore irreversibile. Driver, ad esempio, o lo stack di rete. Infatti, ci sono sistemi operativi che proteggono a questo livello - sono indicati come microkernel architectures.
Il problema con i microkernel, tuttavia, è rappresentato dalle prestazioni. Nelle CPU x86 la protezione della memoria si ottiene con due fattori: lo Current Privilege Level (CPL o 'ring'), un numero compreso tra 0 (accesso massimo) e 3 (modalità utente) e lo Page Table. La tabella di pagina associa gli indirizzi virtuali agli indirizzi fisici e imposta le restrizioni di accesso su ogni pagina (blocco di memoria a 4096 byte). Ogni processo ha una propria tabella di pagine e ogni pagina della tabella può essere limitata impostando un CPL massimo, un flag di sola lettura, un flag di non esecuzione o un contrassegno di assenza di accesso.
La modifica della CPL è un'operazione relativamente veloce (anche se esistono restrizioni di sicurezza su come e quando è consentito farlo). La modifica della tabella delle pagine, tuttavia, è piuttosto costosa, in quanto richiede la cancellazione di una cache nella CPU denominata Translation Lookaside Buffer (TLB).
In genere, in un normale sistema operativo, il sistema operativo riserva il più basso X GB di memoria per i processi utente (generalmente 3 GB è il numero scelto per le architetture a 32 bit). I GB superiori (4 - X) sono mappati direttamente al primo (4 - X) GB di memoria fisica e sono limitati a CPL 0 (solo "ring 0"). Pertanto, il kernel può mettere le sue strutture dati private nell'1GB superiore o giù di lì e accedervi sempre allo stesso indirizzo virtuale, indipendentemente dal processo in esecuzione. Se un processo crea un syscall che richiede una mezza dozzina di sottosistemi per fare qualcosa, nessun problema - puoi semplicemente chiamare le funzioni tra di loro.
Tuttavia, in un sistema microkernel, ciascun sottosistema del kernel riceve la propria tabella di pagine e i propri mapping di indirizzi. Per servire una chiamata utente, la CPU potrebbe dover apportare alcune modifiche alle tabelle delle pagine e questo colpo di prestazioni si somma. Inoltre, ogni sottosistema deve essere preparato ad affrontare i fallimenti delle sue dipendenze, aumentando la complessità del sistema. A causa di questi problemi, i microkernel, in generale, sono stati utilizzati solo come sistemi di ricerca e sistemi operativi giocattolo (ad esempio, minix, GNU HURD).
Detto questo, negli ultimi anni, si è verificata una leggera confusione tra macro e micro-kernel. Ad esempio, in Windows 7, il driver grafico è in effetti isolato dal resto del kernel; se si blocca, il sistema può recuperare. In Linux e OS X, FUSE può caricare i driver del filesystem nello spazio utente; il driver NTFS su questi sistemi, infatti, utilizza questo meccanismo.
perché diventa fuori tema ?? –
Mi sembra una domanda osdev su argomento ... – bdonlan