Primero, en algún nivel siempre tendrá un componente que Can not Fail ™. Si este componente falla, no es posible la recuperación. Por ejemplo, si destruye la tabla de procesos en ejecución, no puede reconstruir esto aparte de reiniciar. Por lo tanto, incluso con la protección de la memoria que limita los bloqueos de este componente para que solo afecten a sí mismos, pueden ocurrir BSOD (o el equivalente).
Pero su punto es bueno - hay una serie de componentes que a menudo pueden reiniciarse sin una falla catastrófica. Controladores, por ejemplo, o la pila de red. De hecho, hay sistemas operativos que hacen protección en este nivel; se los conoce como microkernel architectures.
El problema con los microkernels, sin embargo, es el rendimiento. En las CPU x86, la protección de la memoria se logra con dos cosas: Current Privilege Level (CPL o 'ring'), un número entre 0 (acceso máximo) y 3 (modo de usuario), y Page Table. La tabla de páginas asigna direcciones virtuales a direcciones físicas y establece restricciones de acceso en cada página (bloque de 4096 bytes de memoria). Cada proceso tiene su propia tabla de páginas, y cada página de la tabla de páginas puede restringirse estableciendo un CPL máximo, un indicador de solo lectura, un indicador de no ejecución o un indicador de no acceso.
Cambiar su CPL es una operación relativamente rápida (aunque existen restricciones de seguridad sobre cómo y cuándo puede hacerlo). Sin embargo, cambiar la tabla de páginas es bastante caro, ya que requiere borrar una memoria caché en la CPU llamada Translation Lookaside Buffer (TLB).
Por lo general, en un sistema operativo normal, el sistema operativo reservará la memoria X GB más baja para los procesos del usuario (3 GB suele ser el número elegido para las arquitecturas de 32 bits). Los GB superiores (4 - X) se asignan directamente al primer (4 - X) GB de memoria física, y se restringen a CPL 0 ('anillo 0') solamente. Por lo tanto, el kernel puede poner sus estructuras de datos privadas en el nivel superior de 1 GB y siempre acceder a ellas en la misma dirección virtual, sin importar qué proceso se esté ejecutando. Si un proceso hace que un syscall requiera media docena de subsistemas para hacer algo, no hay problema, puede llamar funciones entre ellos.
Sin embargo, en un sistema de microkernel, cada subsistema de kernel obtiene su propia tabla de páginas y sus propias asignaciones de direcciones. Para atender una llamada de usuario, es posible que la CPU tenga que realizar bastantes cambios en la tabla de páginas, y este golpe de rendimiento se suma. Además, cada subsistema debe estar preparado para enfrentar las fallas de sus dependencias, aumentando la complejidad del sistema. Debido a estos problemas, los microkernels, en general, solo se han usado como sistemas operativos de investigación y de juguete (por ejemplo, minix, GNU HURD).
Dicho esto, en los últimos años, ha habido cierta confusión en la línea entre macro y micro núcleos. Por ejemplo, en Windows 7, el controlador de gráficos es, de hecho, está aislado del resto del kernel; si falla, el sistema puede recuperarse. En Linux y OS X, FUSE puede cargar los controladores del sistema de archivos en el espacio de usuario; el controlador NTFS en estos sistemas, de hecho, usa este mecanismo.
¿por qué se convierte en fuera de tema? –
Esto me suena como una pregunta de osdev sobre el tema ... – bdonlan