Investigador de Google dice que el diseño del kernel de Windows NT aún eclipsa a Linux

Resumen:

Laurie Kirk, una investigadora que ha trabajado como ingeniería inversa en Microsoft durante cuatro años y ahora trabaja en Google, ha reavivado recientemente el debate de décadas entre Windows y Linux. Ella declaró públicamente que el kernel de Windows NT sigue siendo un "milagro de la ingeniería" desde una perspectiva de diseño de ingeniería, e incluso eclipsa a Linux en muchos aspectos.

Kirk enfatizó que lo que admiraba no era el menú Inicio, Copilot o los anuncios de Windows 11, sino la arquitectura del kernel NT subyacente de Windows. Ella cree que NT ha establecido un modelo de objetos y un sistema de seguridad relativamente completo desde el principio, mientras que Linux ha agregado gradualmente mecanismos de seguridad como capacidades, espacios de nombres y SELinux sobre la base del Unix tradicional, por lo que parece más disperso en general.

Kirk dijo en plataformas sociales que si se da la descripción más simple desde la perspectiva de un programador, NT está más cerca de un diseño "orientado a objetos" y tiene un modelo de seguridad muy sólido desde el principio; por el contrario, muchas de las capacidades de seguridad de Linux se agregaron gradualmente más tarde. Ella cree que si hoy se diseña desde cero un kernel de sistema operativo orientado al futuro, la forma final probablemente no se parecerá a Linux, sino que se acercará más a NT, e incluso puede ser similar a alguna rama de BSD.

Windows NT es en realidad la base técnica de todas las versiones principales de Windows desde 1993, incluido el actual Windows 11. Microsoft contrató a Dave Cutler en 1988, quien anteriormente había sido responsable del desarrollo del sistema operativo VMS en DEC. Según Microsoft, un pequeño equipo de antiguos ingenieros de DEC liderados por Cutler pasó unos seis meses desarrollando la especificación antes de empezar a escribir código. Los objetivos iniciales incluían portabilidad, soporte multiprocesador y certificación de seguridad de nivel C2.

El ingeniero retirado de Microsoft, Dave Plummer, también participó en el debate. Señaló que NT no es la primera vez que Cutler diseña un núcleo de sistema operativo desde cero. Anteriormente participó en RSX-11M y VMS, por lo que NT es en realidad la tercera vez que Cutler construye un kernel desde cero.

Sin embargo, NT no reemplaza simplemente VMS con un shell de Windows. Originalmente se llamó NT OS/2, un sistema operativo que enfatizaba la portabilidad. Primero se desarrolló para el procesador Intel i860 y luego se trasladó a la arquitectura MIPS. Microsoft finalmente cambió la dirección principal del producto NT de OS/2 a Win32. Un antecedente importante fue que Windows 3.1 vendió 16 millones de copias en sólo seis meses.

Una de las cosas principales que Kirk admiraba era el diseño de "objetos" de NT. En la propia terminología técnica de Microsoft, NT no es un "sistema operativo orientado a objetos" implementado en lenguajes como C++ en el sentido tradicional, sino que utiliza una arquitectura "basada en objetos". Recursos como procesos, subprocesos, archivos, dispositivos, claves de registro, exclusiones mutuas, trabajos y tokens de acceso se administran como objetos.

El administrador de objetos interno de NT es responsable de crear y destruir estos objetos, mantener el espacio de nombres de los objetos, rastrear qué objetos contiene cada proceso y administrar los derechos de acceso correspondientes. Los diferentes componentes del sistema utilizan estos objetos a través de las interfaces proporcionadas por el componente al que pertenece el objeto, por lo que cuando cambia la implementación interna del componente subyacente, puede evitar afectar a otros componentes hasta cierto punto.

El lugar más fácil para que los programadores comunes de Windows entren en contacto con este diseño es el "identificador". Cuando una aplicación abre un archivo, Windows no simplemente entrega el archivo a la aplicación, sino que devuelve un identificador y registra los permisos que se le han otorgado. Cuando el programa opere con el archivo más adelante, el sistema lo verificará en función de estos permisos. Si se copia un identificador, sus permisos se pueden reducir aún más, pero no se pueden aumentar de la nada mediante la operación de copia.

Kirk cree que este método de gestión relativamente unificado para diferentes recursos del sistema es muy elegante y también es una de las ventajas importantes de la arquitectura NT.

El modelo de seguridad de NT también se basa en recursos, identidades y permisos. Después de que un usuario inicia sesión en Windows, el sistema crea un token de acceso que contiene el identificador de seguridad SID del usuario, el grupo de usuarios al que pertenece y los permisos del sistema relacionados. Los procesos iniciados por los usuarios generalmente obtienen los tokens de acceso correspondientes, y cada objeto que puede protegerse tiene un descriptor de seguridad, que incluye una lista de control de acceso que especifica qué SID pueden obtener qué permisos o deben denegarse.

Cuando un proceso intenta acceder a un objeto, Windows compara el token de acceso con la lista de control de acceso del objeto y devuelve un identificador con los permisos adecuados. Además, los descriptores de seguridad pueden contener listas de control de acceso al sistema con fines de auditoría para registrar el acceso exitoso o fallido a un objeto.

Sin embargo, esto no significa que tener un kernel bien diseñado equivale automáticamente a un sistema operativo absolutamente seguro. Windows NT 3.5 alguna vez recibió una calificación de seguridad C2, pero el entorno de certificación en ese momento era una computadora independiente sin conexión de red, y Microsoft también reforzó los permisos predeterminados para archivos y registro. A medida que Windows ingresa a la era de Internet, los controladores, las configuraciones predeterminadas y los requisitos de compatibilidad acumulados durante décadas también tendrán un gran impacto en la seguridad del sistema.

Una de las principales críticas de Kirk a Linux es que Linux utiliza múltiples mecanismos cooperativos para la seguridad y la gestión de permisos. Las preguntas que planteó incluyeron UID, GID, ACL, cgroups, varias políticas de seguridad, SELinux y permisos del sistema de archivos, etc., y creía que faltaba un diagrama de relación de permisos unificado e intuitivo entre estos mecanismos.

Sin embargo, esta complejidad también es parte de la forma en que está diseñado Linux. UID y GID se utilizan para identificar usuarios y grupos de usuarios, mientras que los permisos de archivos y ACL son responsables de proteger los archivos. Las capacidades pueden separar las capacidades de las cuentas raíz tradicionales, como permitir que un servidor web vincule el puerto 80 sin obtener permisos de raíz completos. Los espacios de nombres permiten a los procesos ver montajes de sistemas de archivos, procesos o entornos de red independientes. La tecnología de contenedores se basa en este mecanismo. Los cgroups son responsables de limitar el uso de recursos como CPU y memoria, y SELinux y otros módulos de seguridad de Linux pueden imponer políticas de seguridad adicionales sobre esta base.

De hecho, muchos de estos mecanismos de Linux se agregaron gradualmente durante el desarrollo del kernel. Por ejemplo, SELinux fue propuesto originalmente por la Agencia de Seguridad Nacional de EE. UU. en forma de un parche independiente en 2001. Posteriormente, Linux estableció el marco del Módulo de seguridad de Linux para que se pueda acceder a diferentes modelos de seguridad a través de ganchos de kernel unificados. Hoy en día, el kernel de Linux ya admite múltiples mecanismos de seguridad, como SELinux, AppArmor, Smack, TOMOYO y Landlock.

Por lo tanto, existen diferencias significativas en las filosofías de diseño de los dos sistemas operativos. NT tiende a centralizar la administración en torno a un modelo de objetos unificado, mientras que Linux presta más atención a la componibilidad, permitiendo que diferentes mecanismos asuman diferentes tareas y permitiendo que las distribuciones, los administradores y los escenarios de aplicaciones se combinen.

Kirk cree que vale la pena revisar esta diferencia hoy en día con el rápido desarrollo de los agentes de inteligencia artificial. La pregunta central que planteó fue: "¿Qué se le permite hacer exactamente a un agente de IA?"

Los programas tradicionales generalmente se ejecutan uno por uno según instrucciones explícitamente emitidas por el usuario, mientras que los agentes de IA pueden realizar continuamente miles de operaciones en unos pocos minutos, generar y ejecutar código por sí mismos, leer archivos y concatenar múltiples permisos para completar tareas complejas. Por lo tanto, el sistema operativo no sólo necesita determinar "quién" está ejecutando el programa, sino que también necesita definir más claramente a qué recursos puede acceder un agente de IA, dentro de qué alcance opera y cómo registrar estos comportamientos.

Kirk cree que el modelo de objetos de NT puede permitir que el sistema operativo establezca relaciones de permisos más claras para diferentes recursos y proporcione un registro de auditoría más centralizado y claro cuando el agente de IA pierde el control. Sin embargo, también admitió que esto sigue siendo una hipótesis arquitectónica más que una conclusión comprobada.

De hecho, Linux ha proporcionado cada vez más herramientas para este problema. Landlock agregado en Linux 5.13 permite que incluso los procesos sin privilegios limiten activamente el sistema de archivos y los recursos de red a los que pueden acceder. Estos límites pueden heredarse de los procesos secundarios y el proceso secundario sólo puede reforzarlos aún más, no relajarlos. Combinado con seccomp, Namespaces, cgroups y varios mecanismos LSM, Linux también puede aislar estrictamente los agentes de IA.

La propia Microsoft se está moviendo en una dirección similar. Microsoft anunció Microsoft Execution Containers, o MXC, en la conferencia Build 2026, lo que permite a los desarrolladores declarar a qué recursos puede acceder el agente de IA y a Windows hacer cumplir estas restricciones durante el tiempo de ejecución. MXC también puede crear cuentas de usuario independientes para los agentes, lo que permite al sistema atribuir cada operación realizada por el agente a una identidad específica. El espacio de trabajo del agente existente de Windows 11 también usa ACL para restringir las cuentas de los agentes para que sus permisos no excedan los del usuario.

En otras palabras, Microsoft ahora está utilizando mecanismos tradicionales de NT, como SID, tokens de acceso y ACL, para resolver el problema de los permisos de los agentes de IA. Aquí es exactamente donde Kirk cree que la arquitectura NT tiene ventajas. Sin embargo, esto no significa que Microsoft haya demostrado que Linux no es capaz de utilizar agentes de IA. Si bien el propio Microsoft está avanzando en su sistema operativo de IA, también ha advertido que los agentes de IA pueden crear nuevo malware y riesgos de seguridad.

Kirk propuso entonces su idea histórica alternativa más interesante: Microsoft debería lanzar un "Open NT" en aquel entonces.

El Open NT que ella imaginó no necesariamente tiene que ser completamente abierto como el software GPL, pero permite a las grandes empresas modificar componentes específicos en el kernel mientras mantiene los estándares básicos de seguridad y compatibilidad establecidos por Microsoft. Por ejemplo, cuando Amazon estaba construyendo la plataforma de computación en la nube EC2 en los primeros días, podía derivar una versión llamada "AmazonNT" de Open NT y modificar el programador, la pila de red o el asignador de memoria por sí solo, sin dejar de cumplir con las especificaciones básicas de compatibilidad y seguridad definidas por Microsoft.

De hecho, Microsoft ha probado un modelo similar hasta cierto punto en el pasado. El programa Shared Source de Microsoft ha proporcionado acceso al código fuente de Windows a aproximadamente 1.600 clientes empresariales, universidades y agencias gubernamentales. En 2001, el Ministerio del Interior de Austria se convirtió en el primer gobierno europeo en obtener el código fuente de Windows XP.

En 2006, Microsoft también lanzó Windows Research Kernel, que permite a los investigadores universitarios modificar el programador y el administrador de memoria de NT para la enseñanza y la investigación. Sin embargo, estos proyectos todavía tienen un intercambio de código fuente limitado y no permiten que empresas como Amazon creen y distribuyan comercialmente sus propias ramas de Windows NT.

En cuanto a por qué Microsoft no ha abierto más NT, el artículo cree que puede implicar ingresos por licencias, derechos de propiedad intelectual, costos de soporte técnico y el compromiso más importante de Microsoft con la compatibilidad con Windows. Permitir que terceros modifiquen el kernel durante mucho tiempo probablemente signifique que Microsoft deba enfrentar una gran cantidad de problemas de compatibilidad y seguridad entre diferentes versiones.

Los desarrolladores de Linux han cuestionado la visión Open NT desde otro ángulo. David Airlie, que ha estado involucrado durante mucho tiempo en el desarrollo del subsistema de gráficos del kernel de Linux, cree que el verdadero problema es el costo a largo plazo de mantener una rama del kernel. Incluso si el código fuente es completamente abierto, si las empresas aún necesitan mantener sus propios administradores o programadores de memoria modificados 20 años después, deben continuar invirtiendo en equipos de ingeniería dedicados.

Airlie señaló que un gran número de empresas han intentado bifurcar versiones de Linux, pero después de unos años a menudo descubren que el costo de mantener sus propias sucursales es demasiado alto y, en última instancia, optan por enviar los cambios nuevamente a la línea principal. La razón por la que pueden existir diferentes implementaciones de JVM en el ecosistema Java durante mucho tiempo es porque tienen clientes comerciales claros y fuentes de ingresos detrás de ellas; mientras que una sucursal del NT que sólo presta servicios a empresas internas puede resultar difícil soportar esos costos a largo plazo.

Si Amazon modifica el programador de NT, entonces las correcciones de seguridad que Microsoft publica cada mes tendrán que volver a fusionarse, probarse y verificarse. Cuanto más tiempo pasa, más se acerca esta rama a un equipo del núcleo del sistema operativo que debe mantenerse de forma independiente. El modelo de Linux consiste en enviar una gran cantidad de cambios requeridos por las empresas a la línea principal tanto como sea posible y ser mantenido conjuntamente por toda la comunidad.

El NT en sí no carece de bagaje histórico. Algunos ingenieros señalaron que el diseño coherente del VMS no se transfirió completamente al NT moderno. El registro de Windows ha sido durante mucho tiempo uno de los componentes del sistema más controvertidos entre los ingenieros.

Otra controversia surge del sistema gráfico. Durante el período de Windows NT 4.0, Microsoft trasladó el Administrador de ventanas, GDI y los controladores de gráficos al espacio del kernel para mejorar el rendimiento de los gráficos. Esto significa que un controlador de gráficos muy problemático puede provocar directamente el fallo de todo el sistema operativo. Luego, Windows 2000 agregó una gran cantidad de mecanismos, como el modelo de controlador de Windows, Plug and Play, administración de energía, WMI y objetos de trabajo.

Por lo tanto, el kernel NT en Windows 11 hoy ya no es el mismo kernel que cuando NT 3.1 se lanzó por primera vez en 1993. Lo que Kirk realmente elogió fueron algunos de los conceptos arquitectónicos básicos cuando se fundó NT, en lugar de pensar que todos los diseños de Windows moderno son inherentemente superiores a Linux.

A juzgar por los resultados históricos, Linux finalmente logró una posición en los campos de servidores y computación en la nube que NT no logró alcanzar. La licencia abierta de Linux permite a cualquier organización modificar el kernel, ejecutarlo en una variedad de hardware y enviar mejoras a la línea principal. La posterior aparición de contenedores, herramientas de desarrollo y enormes ecosistemas como Android han fortalecido aún más este modelo de desarrollo.

Lo interesante es que Microsoft ha estado trabajando duro para que Windows funcione mejor con Linux en los últimos años. El subsistema de Windows para Linux continúa recibiendo mejoras de rendimiento y de red, y Microsoft también ha lanzado funciones como WSL Containers, que permiten a los usuarios ejecutar contenedores de Linux directamente en el entorno de Windows. Google también ha comenzado a agregar soporte WSL a sus propias herramientas de inteligencia artificial.

Al mismo tiempo, Kirk también mencionó BSD. Ella cree que si hoy se rediseña el núcleo del sistema operativo, además de NT, también podría aparecer una arquitectura tipo BSD. Ella cree que la estructura general de BSD es relativamente ordenada y tiene mecanismos de aislamiento como cárceles en sus inicios.

FreeBSD Jails puede limitar los sistemas de archivos, usuarios y entornos de red que ve un proceso, mientras que Capsicum está más cerca del modelo de capacidades enfatizado por Kirk. Después de ingresar al Modo de capacidad, el proceso no puede acceder al espacio de nombres global a voluntad y solo puede usar los permisos que se le otorgan explícitamente a través de descriptores de archivos. Curiosamente, el proyecto Capsicum se completó en la Universidad de Cambridge y recibió financiación para investigación de Google.

Desde esta perspectiva, lo que Kirk realmente está discutiendo no es quién es mejor en todos los escenarios, Windows o Linux, sino una cuestión más básica: cómo el sistema operativo debería representar y controlar los "permisos".

La idea de NT es permitir que los recursos tengan tipos claros, adjuntar permisos de acceso a los recursos y verificarlos y registrarlos de manera uniforme por parte del sistema operativo tanto como sea posible. Linux parte de la base más flexible de Unix y satisface las necesidades de diferentes entornos a través de múltiples mecanismos que se pueden combinar. Ningún método por sí solo puede garantizar la seguridad del sistema.

La aparición de agentes de IA está haciendo que esta cuestión sea aún más importante. En el pasado, la cuestión más importante para los sistemas operativos era confirmar "qué usuario" está realizando la operación; en el futuro, debe responder con más detalle a quién puede representar un agente de IA, a qué recursos puede acceder, durante cuánto tiempo tiene permiso, qué operaciones puede realizar y si el sistema puede demostrar con precisión lo que ha hecho.

Windows NT no se convirtió en el actor dominante en el mundo de los servidores y la computación en la nube, y esa posición finalmente la ocupó Linux. Sin embargo, han pasado más de 30 años desde la llegada de NT 3.1. Windows todavía utiliza los conceptos de diseño originales de objetos, identificadores, tokens de acceso y ACL, y Microsoft ahora está comenzando a utilizar estos mecanismos para resolver el problema de aislamiento de permisos de los agentes de IA.

Por lo tanto, el "Open NT" imaginado por Laurie Kirk puede que solo exista en la historia ficticia para siempre, pero a medida que las computadoras comienzan a realizar más y más tareas para los humanos, todos los sistemas operativos enfrentan un problema cada vez más real: cuando el software comienza a actuar en nombre de los humanos, ¿hasta dónde debemos permitirle llegar?