Quizás deberíamos volver a evaluar los microkernels en la era del hardware moderno

• Los microkernels, que antes eran poco prácticos por su alto overhead, podrían volver a ser una opción realista gracias a la adopción generalizada de IOMMU y memoria compartida
• Aislar drivers y subsistemas en espacio de usuario puede aumentar la seguridad, confiabilidad y modularidad al limitar el alcance de fallas o ataques
• En las décadas de 1980 y 1990, los procesos en espacio de usuario no podían acceder directamente a los dispositivos, por lo que operaciones como leer del disco implicaban llamadas al sistema y cambios de contexto, bloqueos y copias de memoria
• Con IOMMU y colas de comandos compartidas, es posible manejar IPC asíncrono y acceso a dispositivos en la ruta normal sin cambios de contexto, copias entre espacios de direcciones ni bloqueos
• Se pueden aprovechar componentes existentes como Xen, FreeBSD y Linux DRM, por lo que la carga de crear hipervisores y servidores de sistema desde cero tampoco sería grande

---

Estructura de los microkernels y efecto del aislamiento

• Un microkernel es una estructura de kernel que ejecuta en espacio de usuario las funciones excepto la planificación, la gestión del acceso a dispositivos de I/O y la comunicación entre procesos (IPC)
• El aislamiento de subsistemas ofrece tres beneficios
  • Seguridad: una vulnerabilidad en un driver solo podría darle a un atacante permisos de acceso a ese subsistema o driver, no a todo el sistema
  • Confiabilidad: la caída de un subsistema afecta solo a esa parte, no a todo el sistema
  • Modularidad: podría reducir la carga del equipo del kernel de Linux de fusionar todos los drivers de hardware y revisar incluso el funcionamiento interno de cada chip
• Si Windows hubiera sido un sistema de microkernel, el bug de CrowdStrike podría haberse limitado a detener la recopilación de datos de telemetría de algunos responsables de seguridad de TI

Límites de rendimiento del pasado y la solución de IOMMU

• En los microkernels del pasado, los procesos en espacio de usuario no podían acceder directamente a dispositivos específicos, por lo que cada operación requería llamadas al sistema y cambios de contexto, además de costosos bloqueos y copias de memoria
  • Mach fue moviendo gradualmente procesos de espacio de usuario hacia dentro del kernel por problemas de rendimiento, y al final se acercó a un kernel monolítico convencional
• Hoy, las PC incorporan de forma estándar IOMMU desde hace unos 10 años, y si se usa junto con memoria compartida, permite eliminar por completo los cambios de contexto en la ruta normal cuando hay suficientes núcleos
  • Si se acepta un poco de latencia, también se pueden eliminar casi por completo los cambios de contexto en general
  • Un planificador basado en tecnología de virtualización puede estructurarse de forma similar al hipervisor Xen
  • El acceso a dispositivos de I/O lo gestiona el hardware IOMMU
• La IPC puede implementarse asignando buffers compartidos entre procesos y ofreciendo compare-and-swap atómico de enteros
  • El buffer compartido se usa como una cola de comandos en forma de ring buffer, y los punteros de inicio y fin se actualizan atómicamente
  • En la ruta normal se pueden entregar mensajes asíncronos sin cambios de contexto, copias entre espacios de direcciones ni bloqueos; es un método ampliamente usado también en drivers de GPU

Composición de bibliotecas y reutilización de código existente

• En un entorno donde los procesos son guests de VM, las bibliotecas compartidas pueden enlazarse al iniciar el programa, y las funciones que no necesitan ejecutarse en otro proceso pueden manejarse localmente al estilo exokernel
  • En la actualidad, cuando las aplicaciones suelen distribuir sus propios componentes de sistema operativo al estilo Electron, las bibliotecas duplicadas en memoria no son un problema tan grande como hace 30 años
• Las bases principales necesarias para la implementación ya existen
  • Xen ya cuenta con la mayoría de las funciones necesarias para la capa de hipervisor
  • Se pueden construir servidores de red y sistema de archivos como en Mach, pero reutilizando código de FreeBSD
  • DRM ya se basa en buffers de comandos asíncronos, por lo que el subsistema gráfico de Linux puede ejecutarse en espacio de usuario
  • Por conveniencia, también es posible ejecutar el servidor de display y el subsistema gráfico en el mismo proceso

[GN⁺]

Opiniones en Lobste.rs

• La razón por la que Linux incluye todos los drivers es que no existe una API estable para módulos del kernel externos al árbol, y un microkernel no es indispensable para ofrecer una API así

  • Un microkernel tampoco evita la inestabilidad de las API internas; simplemente hace que se cruce el límite entre procesos
    Recuerdo haber visto quejas en LKML de que, incluso suponiendo que todos los drivers de Linux se movieran al espacio de usuario, eso dificultaría los cambios en las API internas

• Creo que los kernels de la familia L4 son conocidos por ser rápidos. También me da curiosidad cómo les va a Redox OS o Fuchsia

  • Los kernels L4 pueden ser rápidos, pero en la práctica solo parecen útiles en sistemas embebidos con una configuración muy fija
    Genode soporta varios kernels, pero en seL4 y otros tiene un rendimiento ridículamente malo. Cuando unos colegas intentaron arrancar una VM de Linux, solo soportaba 32 bits, y aun así tardó varios minutos en arrancar más o menos hasta la mitad
    Hay una razón por la que el fork de Genode del NOVA microhypervisor es la plataforma predeterminada: realmente funciona y su rendimiento es suficiente
  • Al ver la documentación de Redox, todavía realiza cambios de contexto al ensamblar los mensajes de solicitud, probablemente como una etapa de verificación
    Como usa un búfer circular, si el receptor ya se está ejecutando en otro core, quizá no haga falta un segundo cambio de contexto. Si se interpretan los mensajes sin cambio de contexto, el receptor tendría que validarlos, lo que podría ampliar demasiado la superficie de ataque, aunque parece haber margen para mitigarlo con una biblioteca dinámica provista por el kernel
    No soy experto, pero siento que el texto original omite algunas consideraciones importantes

• QNX es conocido como un microkernel rápido; me pregunto qué hizo bien

  • El QNX que probé no era rápido
    Hace tiempo, un amigo y yo quedamos fascinados por la elegancia de los microkernels, en especial QNX, e implementamos un problema de procesamiento de video basado en FireWire. El código era simple y elegante, pero terriblemente lento. En esa época, al agregar soporte de transferencias isócronas basadas en DMA al driver 1394 para Linux en unas 12 horas, el rendimiento mejoró mucho, y eso también disipó el escepticismo sobre usar Linux en los equipos de clasificación óptica de la empresa
    Los ideales de QNX, los microkernels y el paso de mensajes siguen siendo excelentes, pero para masificarse hay que reducir mucho el costo de transferir datos entre procesos
    Ahora desarrollo aplicaciones web con Elixir y disfruto del mismo aislamiento de procesos que promocionaba QNX. Como no son tareas críticas en rendimiento como el procesamiento óptico, está bien, pero Elixir/BEAM tiene el mismo problema de copiado de datos

• Aunque Mach no haya logrado independizar por completo sus componentes como se concibió originalmente, he oído que no se convirtió en un kernel monolítico común, y que su arquitectura todavía aporta ventajas
  En benchmarks clásicos de listado de archivos POSIX, si se llama a readdir() y stat() para cada elemento, un microkernel inevitablemente queda en desventaja. Pero si se usa una API de procesamiento por lotes como io_uring para reducir la frecuencia de llamadas al sistema, la alta latencia quizá no sea una debilidad tan grande

  • El artículo de Liedtke “on μ-Kernel Construction”, 1995 atribuía la lentitud de Mach a su gran uso de caché, es decir, a un diseño que no era lo bastante pequeño
    Linux tampoco puede seguir la velocidad de línea si hace una llamada al sistema por cada paquete de red. El procesamiento por lotes es importante tanto en Linux como en los microkernels

• Un participante reciente e interesante en este campo es HongMeng, aunque lamentablemente es software propietario

• Mientras el costo de mover datos no se reduzca en al menos un orden de magnitud, parece difícil que los microkernels sean suficientemente competitivos
  En teoría son elegantes y limpios, pero la realidad es compleja, así que quizá el kernel también tenga que ser complejo hasta cierto punto para lidiar con esa complejidad

• Me gustan las arquitecturas correctas, pero creo que el dominio de Linux también se debió mucho a factores secundarios además de la tecnología pura. Me gustaría leer un análisis de eso en varias dimensiones