Todo sistema operativo comienza antes de ser realmente él mismo. La CPU arranca en un entorno definido por la plataforma, el firmware inicializa suficiente hardware para cargar el primer ejecutable, y ese ejecutable prepara la máquina para el kernel. Solo después de que esta cadena haya hecho su trabajo puede el sistema operativo empezar a imponer sus propias reglas. Es fácil tratar ese camino inicial como simple fontanería, pero el proceso de arranque forma parte del modelo de seguridad.

Los sistemas operativos suelen asociarse con C. Esa asociación es comprensible. C es pequeño, predecible, cercano a la máquina y ha dominado históricamente el trabajo de kernel. Da al programador acceso directo a memoria, registros, layout y convenciones de llamada. Esas son exactamente las cosas que necesita un kernel. También son exactamente las cosas que hacen que los kernels sean difíciles de asegurar. EriX está escrito principalmente en Rust porque el proyecto se construye alrededor de una idea central:

Las discusiones de seguridad suelen centrarse en errores individuales: un desbordamiento de búfer un fallo de diputado confundido un parser sin comprobaciones suficientes una ruta de escalada de privilegios Esos errores importan, pero son síntomas de una pregunta más profunda: ¿Cuánto código debe ser correcto para que el sistema siga siendo seguro? Ese código es la base de cómputo confiable, normalmente abreviada como TCB. El tamaño y la forma de la TCB determinan cuánto código debe ser confiado, auditado, probado y razonado.

Pocos debates de diseño de sistemas operativos han durado tanto como el debate entre microkernels y kernels monolíticos. En la superficie, la diferencia parece simple: los kernels monolíticos mantienen la mayoría de los servicios del sistema operativo dentro del kernel los microkernels mueven la mayoría de los servicios al espacio de usuario En la práctica, el compromiso es más sutil. La verdadera pregunta no es si una estructura es universalmente más rápida, más limpia o más segura.

La mayoría de los sistemas operativos modernos se construyen sobre décadas de código acumulado, bibliotecas y dependencias externas. Aunque este ecosistema permite un desarrollo rápido, también introduce complejidad, supuestos ocultos y riesgos de seguridad potencialmente no examinados. EriX adopta un enfoque diferente. Se desarrolla como un sistema operativo de sala limpia, lo que significa que cada componente - desde el cargador de arranque hasta los servicios de espacio de usuario - se implementa dentro del propio proyecto, sin incorporar código fuente externo ni bibliotecas de terceros.

Los sistemas operativos modernos imponen límites de seguridad entre procesos, archivos, dispositivos y usuarios. Sin embargo, la forma en que se implementan estos límites varía de manera significativa entre distintos diseños de sistema. La mayoría de los sistemas operativos convencionales dependen del control de acceso basado en identidad y de los espacios de nombres globales. Los sistemas operativos basados en capacidades adoptan un enfoque fundamentalmente distinto: representan la autoridad de forma explícita y la convierten en un concepto de primer nivel.

Los sistemas operativos se encuentran entre los programas más complejas jamás construidas. Gestionan memoria, planifican cómputo, controlan hardware y hacen cumplir los límites de seguridad que protegen cada aplicación que se ejecuta en una máquina. Sin embargo, muchos de los sistemas operativos de los que dependemos hoy están construidos sobre ideas arquitectónicas que se remontan a varias décadas. Aunque estos sistemas son extraordinariamente potentes y están muy probados, también arrastran décadas de complejidad acumulada.