¿Es un kernel monolítico más seguro que un microkernel para un sistema operativo pequeño?

Los microkernels generalmente se consideran más seguros, no solo desde el punto de vista teórico. Por lo general, sus capacidades son más restringidas que las de los núcleos monolíticos de "propósito general" y, por lo tanto, contienen menos errores simplemente porque su base de código es más pequeña. A la inversa, cuanto más código ejecute con altos privilegios, mayores serán sus posibilidades de desastre.

Desde el punto de vista teórico, hay varios puntos clave por los que un microkernel es inherentemente más seguro (siempre que se implemente correctamente):

1. separación de los controladores del kernel (y entre ellos): un controlador de red / audio malicioso o defectuoso no puede fallar o incluso modificar de forma silenciosa el kernel (u otro controlador o aplicación de usuario). Una de las piedras angulares importantes de esta separación es la implementación de IPC mediante el paso de mensajes en lugar de, por ejemplo. Memoria compartida, ya que permite al núcleo desinfectar los datos transferidos. Lo mismo se aplica a los procesos de usuario "normales", obviamente. También es una de las mayores penalizaciones de rendimiento en comparación con los núcleos monolíticos.

2. Los controladores, al ser procesos separados, pueden ejecutarse en un anillo de protección diferente al del microkernel y las aplicaciones que no requieren cualquier acceso de hardware en absoluto. Esto tiene que ser soportado por el hardware, por supuesto.

3. La base de código Leaner permite la verificación formal de algunos microkernels incluyendo la corrección de extremo a extremo de seL4 (logro extraíble, si me preguntas). Por lo tanto, una especificación bien escrita puede dar como resultado resultados esperados solo . Esto hace que el anexo sobre la implementación anterior sea redundante.

Aparte de eso, los microkernels también son más seguros : un controlador defectuoso puede reiniciarse sin que el resto del sistema se vea afectado (esto obviamente exige que las aplicaciones que usan ese controlador sean un poco resistentes frente a las fallas de los controladores). Eso significa que un controlador de pantalla defectuoso en un avión de pasajeros no solo no puede derribar todo el sistema de control de la aeronave, sino que ni siquiera provoca la necesidad de un reinicio completo que demore varios segundos (que no tiene cuando aterriza). , despegando o volando en mal tiempo). El ejemplo clásico puede ser INTEGRITY (178B) - tenga en cuenta que (como muchos núcleos similares / sistemas) carece de cosas como la asignación de memoria dinámica, que es solo un tipo de comodidad que debe vivir si quiere poner restricciones como la ejecución en tiempo real en su sistema.

En teoría, un microkernel, al colocar la mayor parte del código del controlador en el espacio del usuario, es más resistente frente a los ataques: un ataque contra un controlador no se puede usar fácilmente para aprovechar el acceso a los otros controladores, o para obtener un nivel de kernel privilegios Además, el tamaño reducido del kernel le da una superficie de ataque mucho más pequeña.

En la práctica, la arquitectura del kernel es solo un aspecto menor de la seguridad. La atención del diseñador a la seguridad y la calidad de la implementación tiene un impacto mucho mayor.