Articulo de referencia

Anillo de protección

Anillos de privilegios para x86 disponibles en modo protegido En ciencias de la computación , los dominios de protección jerárquicos , [ 1 ] [ 2 ] a menudo llamados anillos de p...

Anillos de privilegios para x86 disponibles en modo protegido

En ciencias de la computación , los dominios de protección jerárquicos , [ 1 ] [ 2 ] a menudo llamados anillos de protección , son mecanismos para proteger los datos y la funcionalidad de fallas (al mejorar la tolerancia a fallas ) y comportamientos maliciosos (al proporcionar seguridad informática ).

Los sistemas operativos de las computadoras proporcionan diferentes niveles de acceso a los recursos. Un anillo de protección es uno de los dos o más niveles o capas jerárquicas de privilegio dentro de la arquitectura de un sistema informático . Generalmente, esto se implementa mediante hardware, a través de algunas arquitecturas de CPU que proporcionan diferentes modos de CPU a nivel de hardware o microcódigo . Los anillos se organizan en una jerarquía desde el más privilegiado (el de mayor confianza, generalmente numerado como cero) hasta el menos privilegiado (el de menor confianza, generalmente con el número de anillo más alto). En la mayoría de los sistemas operativos, el Anillo 0 es el nivel con más privilegios e interactúa más directamente con el hardware físico, como ciertas funciones de la CPU (por ejemplo, los registros de control) y los controladores de E/S.

Se proporcionan mecanismos especiales para permitir que un anillo externo acceda a los recursos de un anillo interno de forma predefinida, en lugar de permitir un uso arbitrario. Controlar correctamente el acceso entre anillos puede mejorar la seguridad al impedir que los programas de un anillo o nivel de privilegio hagan un uso indebido de los recursos destinados a programas de otro. Por ejemplo, se debe impedir que el software espía que se ejecuta como programa de usuario en el Anillo 3 active una cámara web sin informar al usuario, ya que el acceso al hardware debería ser una función del Anillo 1 reservada para los controladores de dispositivos . Los programas como los navegadores web que se ejecutan en anillos de mayor numeración deben solicitar acceso a la red, un recurso restringido a un anillo de menor numeración.

X86S , una arquitectura de Intel cancelada que se publicaría en 2024, solo tiene los anillos 0 y 3. Los anillos 1 y 2 iban a eliminarse en X86S, ya que los sistemas operativos modernos no los utilizan. [ 3 ] [ 4 ]

Implementaciones

Los múltiples anillos de protección fueron uno de los conceptos más revolucionarios introducidos por el sistema operativo Multics , un predecesor altamente seguro de la actual familia de sistemas operativos Unix . El ordenador central GE 645 tenía cierto control de acceso por hardware, incluidos los mismos dos modos que tenían las otras máquinas de la serie GE-600, y permisos a nivel de segmento en su unidad de gestión de memoria ("Unidad de Adición"), pero eso no era suficiente para proporcionar soporte completo para anillos en hardware, por lo que Multics los soportaba capturando las transiciones de anillo en software; [ 5 ] su sucesor, el Honeywell 6180 , los implementó en hardware, con soporte para ocho anillos; [ 6 ] Los anillos de protección en Multics estaban separados de los modos de CPU; el código en todos los anillos excepto el anillo 0, y parte del código del anillo 0, se ejecutaba en modo esclavo. [ 7 ]

Sin embargo, la mayoría de los sistemas de propósito general utilizan solo dos anillos, incluso si el hardware en el que se ejecutan proporciona más modos de CPU . Por ejemplo, Windows 7 y Windows Server 2008 (y sus predecesores) utilizan solo dos anillos, donde el anillo 0 corresponde al modo kernel y el anillo 3 al modo usuario , [ 8 ] porque las versiones anteriores de Windows NT se ejecutaban en procesadores que admitían solo dos niveles de protección. [ 9 ]

Muchas arquitecturas de CPU modernas (incluida la popular arquitectura Intel x86 ) incluyen algún tipo de protección de anillo, aunque el sistema operativo Windows NT , al igual que Unix, no utiliza completamente esta característica. OS/2 sí utiliza, en cierta medida, tres anillos: [ 10 ] anillo 0 para el código del núcleo y los controladores de dispositivos, anillo 2 para el código privilegiado (programas de usuario con permisos de acceso de E/S) y anillo 3 para el código no privilegiado (casi todos los programas de usuario). En DOS , el núcleo, los controladores y las aplicaciones normalmente se ejecutan en el anillo 3 (sin embargo, esto es exclusivo del caso en que se utilizan controladores en modo protegido o extensores de DOS; como un sistema operativo en modo real, el sistema se ejecuta prácticamente sin protección), mientras que los administradores de memoria 386 como EMM386 se ejecutan en el anillo 0. Además de esto, DR-DOS ' EMM386 3.xx puede ejecutar opcionalmente algunos módulos (como DPMS ) en el anillo 1 en su lugar. OpenVMS utiliza cuatro modos denominados (en orden de privilegios decrecientes): Kernel, Ejecutivo, Supervisor y Usuario.

Si bien la arquitectura x86 cuenta con cuatro anillos de protección, lo más común es que solo tenga dos. Incluso en x86, la mayoría de los sistemas operativos solo utilizan los anillos 0 y 3.

El renovado interés por esta estructura de diseño surgió con la proliferación del software Xen VMM , el debate continuo sobre los núcleos monolíticos frente a los micronúcleos (en particular en los grupos de noticias de Usenet y los foros web ), la estructura de diseño Ring-1 de Microsoft como parte de su iniciativa NGSCB y los hipervisores basados ​​en la virtualización x86, como Intel VT-x (anteriormente Vanderpool).

El sistema Multics original tenía ocho anillos, pero muchos sistemas modernos tienen menos. El hardware siempre conoce el anillo actual del hilo de instrucción en ejecución , gracias a un registro de máquina especial. En algunos sistemas, las áreas de memoria virtual se asignan a números de anillo en el hardware. Un ejemplo es el Data General Eclipse MV/8000 , en el que los tres bits superiores del contador de programa (PC) servían como registro de anillo. Así, el código que se ejecuta con el PC virtual configurado en 0xE200000, por ejemplo, estaría automáticamente en el anillo 7, y la llamada a una subrutina en una sección diferente de la memoria provocaría automáticamente una transferencia de anillo.

El hardware restringe severamente la forma en que el control puede transferirse de un anillo a otro, e impone restricciones sobre los tipos de acceso a memoria que se pueden realizar entre anillos. Tomando como ejemplo la arquitectura x86, existe una estructura de puerta especial a la que hace referencia la instrucción de llamada , la cual transfiere el control de forma segura hacia puntos de entrada predefinidos en anillos de nivel inferior (más confiables); esto funciona como una llamada de supervisor en muchos sistemas operativos que utilizan la arquitectura de anillo. Las restricciones de hardware están diseñadas para limitar las oportunidades de vulneraciones de seguridad accidentales o maliciosas. Además, el anillo con mayores privilegios puede contar con capacidades especiales (como el direccionamiento de memoria real que omite el hardware de memoria virtual).

La arquitectura ARM versión 7 implementa tres niveles de privilegio: aplicación (PL0), sistema operativo (PL1) e hipervisor (PL2). Curiosamente, el nivel  0 (PL0) es el de menor privilegio, mientras que el nivel  2 es el de mayor privilegio. [ 11 ] ARM versión 8 implementa cuatro niveles de excepción: aplicación (EL0), sistema operativo (EL1), hipervisor (EL2) y monitor seguro/firmware (EL3), para AArch64 [ 12 ] : D1-2454 y AArch32. [ 12 ] : G1-6013

En algunos sistemas, la protección de anillo se puede combinar con los modos de procesador ( modo maestro/núcleo/privilegiado/supervisor frente a modo esclavo/no privilegiado/usuario). Los sistemas operativos que se ejecutan en hardware compatible con ambos modos pueden utilizar ambas formas de protección o solo una.

El uso eficaz de la arquitectura de anillo requiere una estrecha cooperación entre el hardware y el sistema operativo. Los sistemas operativos diseñados para funcionar en múltiples plataformas de hardware pueden hacer un uso limitado de los anillos si estos no están presentes en todas las plataformas compatibles. A menudo, el modelo de seguridad se simplifica a "núcleo" y "usuario", incluso si el hardware proporciona una granularidad más fina a través de los anillos. [ 13 ]

Modos

Modo supervisor

En términos informáticos, el modo supervisor es un indicador mediado por hardware que puede ser modificado por el código que se ejecuta en el software del sistema. Las tareas o subprocesos del sistema pueden tener este indicador activado mientras se ejecutan, mientras que las aplicaciones de usuario no. Este indicador determina si es posible ejecutar operaciones de código máquina, como modificar registros para diversas tablas de descriptores, o realizar operaciones como deshabilitar interrupciones. La idea de tener dos modos de operación diferentes proviene del principio de que "a mayor poder, mayor responsabilidad" : se confía en que un programa en modo supervisor nunca fallará, ya que un fallo podría provocar el colapso de todo el sistema informático. 

El modo supervisor es "un modo de ejecución en algunos procesadores que permite la ejecución de todas las instrucciones, incluidas las instrucciones privilegiadas. También puede dar acceso a un espacio de direcciones diferente, al hardware de gestión de memoria y a otros periféricos. Este es el modo en el que normalmente se ejecuta el sistema operativo". [ 14 ]

En un núcleo monolítico , el sistema operativo se ejecuta en modo supervisor y las aplicaciones en modo usuario. Otros tipos de sistemas operativos , como los que utilizan un exokernel o un microkernel , no necesariamente comparten este comportamiento.

Algunos ejemplos del mundo de los ordenadores personales:

  • Linux , macOS y Windows son tres sistemas operativos que utilizan el modo supervisor/usuario. Para realizar funciones especializadas, el código en modo usuario debe realizar una llamada al sistema en modo supervisor o incluso al espacio del kernel, donde el código de confianza del sistema operativo ejecutará la tarea necesaria y devolverá la ejecución al espacio de usuario. Se puede añadir código adicional al espacio del kernel mediante módulos del kernel cargables , pero solo por un usuario con los permisos necesarios, ya que este código no está sujeto a las limitaciones de control de acceso y seguridad del modo usuario.
  • DOS (siempre que no se cargue ningún administrador de memoria 386 como EMM386 ), así como otros sistemas operativos sencillos y muchos dispositivos integrados, funcionan permanentemente en modo supervisor, lo que significa que los controladores se pueden escribir directamente como programas de usuario.

La mayoría de los procesadores tienen al menos dos modos diferentes. Los procesadores x86 tienen cuatro modos distintos, divididos en cuatro anillos. Los programas que se ejecutan en el Anillo 0 pueden interactuar libremente con el sistema, y ​​el código que se ejecuta en el Anillo 3 debería poder fallar en cualquier momento sin afectar al resto del sistema. Los Anillos 1 y 2 se utilizan con poca frecuencia, pero podrían configurarse con diferentes niveles de acceso.

En la mayoría de los sistemas existentes, el cambio del modo de usuario al modo kernel tiene un alto costo asociado en el rendimiento. Se ha medido que, en la solicitud básica getpid, cuesta entre 1000 y 1500 ciclos en la mayoría de las máquinas. De estos, solo unos 100 corresponden al cambio propiamente dicho (70 del espacio de usuario al espacio kernel y 40 de vuelta), el resto es "sobrecarga del kernel". [ 15 ] [ 16 ] En el microkernel L3 , la minimización de esta sobrecarga redujo el costo total a alrededor de 150 ciclos. [ 15 ]

Maurice Wilkes escribió: [ 17 ]

... finalmente quedó claro que la protección jerárquica que proporcionaban los anillos no se ajustaba del todo a los requisitos del programador del sistema y ofrecía poca o ninguna mejora respecto al sistema simple de solo dos modos. Los anillos de protección se prestaban a una implementación eficiente en hardware, pero poco más se podía decir de ellos. [...] El atractivo de la protección granular persistió, incluso después de comprobar que los anillos de protección no ofrecían la solución... Esto, una vez más, resultó ser un callejón sin salida...

Para mejorar el rendimiento y el determinismo, algunos sistemas colocan en modo kernel funciones que probablemente se considerarían lógica de aplicación, en lugar de controladores de dispositivos; se citan como ejemplos las aplicaciones de seguridad ( control de acceso , cortafuegos , etc.) y los monitores del sistema operativo. Al menos un sistema de gestión de bases de datos embebido , e Xtreme DB Kernel Mode , se ha desarrollado específicamente para su implementación en modo kernel, con el fin de proporcionar una base de datos local para las funciones de aplicación basadas en el kernel y eliminar los cambios de contexto que se producirían cuando las funciones del kernel interactúan con un sistema de base de datos que se ejecuta en modo usuario. [ 18 ]

En ocasiones, las funciones también se mueven entre anillos en la dirección opuesta. El kernel de Linux, por ejemplo, inyecta en los procesos una sección vDSO que contiene funciones que normalmente requerirían una llamada al sistema, es decir, una transición de anillo. En lugar de realizar una llamada al sistema, estas funciones utilizan datos estáticos proporcionados por el kernel. Esto evita la necesidad de una transición de anillo y, por lo tanto, es más ligero que una llamada al sistema. La función gettimeofday puede proporcionarse de esta manera.

Modo hipervisor

Los procesadores recientes de Intel y AMD ofrecen instrucciones de virtualización x86 para que un hipervisor controle  el acceso al hardware del Anillo 0. Aunque son incompatibles entre sí, tanto Intel VT-x (nombre en clave "Vanderpool") como AMD-V (nombre en clave "Pacifica") permiten que un sistema operativo invitado ejecute  operaciones del Anillo 0 de forma nativa sin afectar a otros sistemas invitados ni al sistema operativo anfitrión.

Antes de la virtualización asistida por hardware , los sistemas operativos invitados se ejecutaban en el anillo  1. Cualquier intento que requiera un nivel de privilegio superior (anillo  0) generará una interrupción que se gestionará mediante software; esto se denomina "Capturar y emular".

Para facilitar la virtualización y reducir la sobrecarga causada por la razón anterior, VT-x y AMD-V permiten que el invitado se ejecute en el Anillo  0. VT-x introduce la Operación VMX Root/Non-root: el hipervisor se ejecuta en el modo de Operación VMX Root, que posee el privilegio más alto. El sistema operativo invitado se ejecuta en el modo de Operación VMX Non-Root, lo que le permite operar en el anillo  0 sin tener privilegios de hardware reales. La operación VMX non-root y las transiciones VMX se controlan mediante una estructura de datos llamada control de máquina virtual. [ 19 ] Estas extensiones de hardware permiten que la virtualización clásica "Trap and Emulate" se ejecute en la arquitectura x86, pero ahora con soporte de hardware.

Nivel de privilegio

En el conjunto de instrucciones x86, un nivel de privilegio controla el acceso del programa que se ejecuta en el procesador a recursos como regiones de memoria, puertos de E/S e instrucciones especiales. Existen cuatro niveles de privilegio, desde el 0 (el de mayor privilegio) hasta el 3 (el de menor privilegio). La mayoría de los sistemas operativos modernos utilizan el nivel 0 para el núcleo/ejecutivo y el nivel 3 para los programas de aplicación. Cualquier recurso disponible para el nivel n también está disponible para los niveles del 0 al n, por lo que los niveles de privilegio forman anillos. Cuando un proceso con menos privilegios intenta acceder a un proceso con más privilegios, se notifica al sistema operativo una excepción de fallo de protección general .

No es necesario utilizar los cuatro niveles de privilegio. Los sistemas operativos actuales con amplia cuota de mercado, incluidos Microsoft Windows , macOS , Linux , iOS y Android, utilizan principalmente un mecanismo de paginación con un solo bit para especificar el nivel de privilegio como Supervisor o Usuario (bit U/S). Windows NT utiliza el sistema de dos niveles. [ 20 ] El código que se ejecuta en modo real se ejecuta en el nivel 0 (nivel de privilegio más alto), mientras que el código que se ejecuta en modo virtual-8086 se ejecuta en el nivel 3. [ 21 ]

Entre los posibles usos futuros de los múltiples niveles de privilegio compatibles con la familia de arquitecturas x86 se incluyen la contenerización y las máquinas virtuales . El núcleo del sistema operativo anfitrión podría utilizar instrucciones con acceso de privilegio completo ( modo kernel ), mientras que las aplicaciones que se ejecutan en el sistema operativo invitado en una máquina virtual o contenedor podrían utilizar el nivel más bajo de privilegios en modo usuario. El núcleo de la máquina virtual y del sistema operativo invitado podrían utilizar un nivel intermedio de privilegio de instrucción para invocar y virtualizar operaciones en modo kernel, como llamadas al sistema, desde la perspectiva del sistema operativo invitado. [ 22 ]

IOPL

El indicador IOPL ( Nivel de privilegio de E/S ) es un indicador presente en todas las CPU x86 compatibles con IA-32 . Ocupa los bits 12 y 13 del registro FLAGS . En modo protegido y modo largo , muestra el nivel de privilegio de E/S del programa o tarea actual. El Nivel de privilegio actual (CPL) (CPL0, CPL1, CPL2, CPL3) de la tarea o programa debe ser menor o igual que el IOPL para que la tarea o programa pueda acceder a los puertos de E/S .

El IOPL se puede cambiar usando POPF(D)y IRET(D)solo cuando el nivel de privilegio actual es Ring 0.

Además de IOPL, los permisos de puerto de E/S en TSS también participan en la determinación de la capacidad de una tarea para acceder a un puerto de E/S.

Misceláneas

En los sistemas x86, la virtualización de hardware x86 ( VT-x y SVM ) se denomina "anillo  −1", el modo de administración del sistema se denomina "anillo  −2", y el Intel Management Engine y el AMD Platform Security Processor a veces se denominan "anillo  −3". [ 23 ]

Uso de las características del hardware

Muchas arquitecturas de hardware de CPU ofrecen mucha más flexibilidad de la que aprovechan los sistemas operativos que normalmente ejecutan. El uso adecuado de los modos complejos de la CPU requiere una estrecha cooperación entre el sistema operativo y la CPU, lo que tiende a vincular el SO a la arquitectura de la CPU. Cuando el SO y la CPU están diseñados específicamente para funcionar juntos, esto no supone un problema (aunque algunas características del hardware pueden quedar sin explotar), pero cuando el SO está diseñado para ser compatible con múltiples arquitecturas de CPU diferentes, gran parte de las características del modo de la CPU pueden ser ignoradas por el SO. Por ejemplo, la razón por la que Windows utiliza solo dos niveles (anillo 0 y anillo 3) es que algunas arquitecturas de hardware compatibles en el pasado (como PowerPC o MIPS ) implementaban solo dos niveles de privilegio. [ 8 ]

Multics era un sistema operativo diseñado específicamente para una arquitectura de CPU particular (que a su vez fue diseñada específicamente para Multics), y aprovechaba al máximo los modos de CPU disponibles. Sin embargo, era una excepción a la regla. Hoy en día, este alto grado de interoperabilidad entre el sistema operativo y el hardware no suele ser rentable, a pesar de las ventajas potenciales en cuanto a seguridad y estabilidad.

En última instancia, el propósito de los distintos modos de operación de la CPU es proporcionar protección de hardware contra la corrupción accidental o deliberada del entorno del sistema (y las correspondientes brechas de seguridad del sistema) por parte del software. Solo las partes "confiables" del software del sistema pueden ejecutarse en el entorno sin restricciones del modo kernel, y, en diseños paradigmáticos, solo cuando sea absolutamente necesario. Todo el demás software se ejecuta en uno o más modos de usuario. Si un procesador genera una condición de fallo o excepción en un modo de usuario, en la mayoría de los casos la estabilidad del sistema no se ve afectada; si un procesador genera una condición de fallo o excepción en el modo kernel, la mayoría de los sistemas operativos detendrán el sistema con un error irrecuperable. Cuando existe una jerarquía de modos (seguridad basada en anillos), los fallos y las excepciones en un nivel de privilegio pueden desestabilizar solo los niveles de privilegio superiores. Por lo tanto, un fallo en el Anillo 0 (el modo kernel con el privilegio más alto) provocará el bloqueo de todo el sistema, pero un fallo en el Anillo 2 solo afectará a los Anillos 3 y posteriores, y al propio Anillo 2, como máximo.

Las transiciones entre modos quedan a discreción del hilo en ejecución cuando la transición es de un nivel de privilegio alto a uno de privilegio bajo (como del modo kernel al modo usuario), pero las transiciones de niveles de privilegio inferiores a superiores solo pueden tener lugar a través de "puertas" seguras controladas por hardware que se atraviesan mediante la ejecución de instrucciones especiales o cuando se reciben interrupciones externas.

Los sistemas operativos de microkernel intentan minimizar la cantidad de código que se ejecuta en modo privilegiado, por motivos de seguridad y elegancia .

Véase también

Notas

  1. Por ejemplo, en IBM OS/360 a través de z/OS , algunas tareas del sistema se ejecutan en la clave de estado de problema 0.

Referencias

  1. Karger, Paul A.; Herbert, Andrew J. (1984). Una arquitectura de capacidad aumentada para brindar soporte a la seguridad reticular y la trazabilidad del acceso . Simposio IEEE de 1984 sobre seguridad y privacidad. pág.  2. doi : 10.1109/SP.1984.10001 . ISBN 0-8186-0532-4. S2CID 14788823 . 
  2. Binder, W. (2001). "Diseño e implementación del núcleo del agente móvil J-SEAL2". Actas del Simposio de 2001 sobre Aplicaciones e Internet . págs. 35–42 . doi : 10.1109/SAINT.2001.905166 . ISBN  0-7695-0942-8. S2CID 11066378 . 
  3. "Visualizando una arquitectura Intel simplificada para el futuro" . Intel . Consultado el 28 de mayo de 2024 .
  4. ^ Tanembaum, Andrew S. (2015). Sistemas operativos modernos (4ª ed.). Pearson . págs. 479– 480. ISBN   978-0-13-359162-0Durante muchos años , el x86 ha admitido cuatro modos o anillos de protección [...]. El anillo 3 es el menos privilegiado [...]. El anillo 0 es el más privilegiado [...]. Los dos anillos restantes no son utilizados por ningún sistema operativo actual.
  5. "Una arquitectura de hardware para implementar anillos de protección" . Communications of the ACM . 15 (3). Marzo de 1972. Recuperado el 27 de septiembre de 2012 .
  6. "Glosario de Multics - anillo" . Consultado el 27 de septiembre de 2012 .
  7. La memoria virtual Multics, parte 2 (PDF) . Honeywell Information Systems. Junio ​​de 1972. págs. 160–161 . 
  8. ^ Russinovich , Mark E.; David A. Salomón (2005). Componentes internos de Microsoft Windows (4 ed.). Prensa de Microsoft. págs.16 .ISBN   978-0-7356-1917-3.
  9. Russinovich, Mark (2012). Windows Internals Part 1 (6.ª ed.). Redmond, Washington: Microsoft Press. p. 17. ISBN   978-0-7356-4873-9La razón por la que Windows utiliza solo dos niveles es que algunas arquitecturas de hardware compatibles en el pasado (como Compaq Alpha y Silicon Graphics MIPS ) implementaban solo dos niveles de privilegio.
  10. "Referencia de controladores de dispositivos de presentación para OS/2 – 5. Introducción a los controladores de presentación de OS/2" . Archivado del original el 15 de junio de 2015. Consultado el 13 de junio de 2015 .
  11. Manual de referencia de la arquitectura ARM, ediciones ARMv7-A y ARMv7-R . Arm Ltd. pág. B1 - 1136. 
  12. 1 2 Manual de referencia de la arquitectura Armv8, para arquitectura de perfil A. Arm Ltd.
  13. ^ Tanembaum, Andrew S. (2015). Sistemas operativos modernos (4ª ed.). Pearson . págs. 479– 480. ISBN   978-0-13-359162-0Durante muchos años , el x86 ha admitido cuatro modos o anillos de protección [...]. El anillo 3 es el menos privilegiado [...]. El anillo 0 es el más privilegiado [...]. Los dos anillos restantes no son utilizados por ningún sistema operativo actual.
  14. «modo supervisor» . FOLDOC . 15 de febrero de 1995.
  15. 1 2 Jochen Liedtke (diciembre de 1995). "Sobre la construcción del µ-kernel" . Actas del 15º Simposio ACM sobre Principios de Sistemas Operativos (SOSP) .
  16. Ousterhout, JK (1990). ¿Por qué los sistemas operativos no se vuelven tan rápidos como el hardware? . Conferencia de Verano de Usenix. Naheim, CA. pp. 247–256 . 
  17. Maurice Wilkes (abril de 1994). "Sistemas operativos en un mundo cambiante" . ACM SIGOPS Operating Systems Review . 28 (2): 9– 21. doi : 10.1145/198153.198154 . ISSN 0163-5980 . S2CID 254134 .  
  18. Gorine, Andrei; Krivolapov, Alexander (mayo de 2008). "Bases de datos en modo kernel: una tecnología DBMS para aplicaciones de alto rendimiento" . Dr. Dobb's Journal .
  19. Manual del desarrollador de software para arquitecturas Intel® 64 e IA-32, volumen 3C (PDF) . Intel Cooperation (publicado en septiembre de 2016). 2016. págs. 1–3 . 
  20. Russinovich, Mark E.; Solomon, David A. (2005). Microsoft Windows Internals (4.ª ed.). Microsoft Press. pág. 16. ISBN   978-0-7356-1917-3.
  21. Sunil Mathur. Microprocesador 8086: Arquitectura, programación e interconexión ( Edición de Economía Oriental). PHI Learning. 
  22. Anderson, Thomas; Dahlin, Michael (21 de agosto de 2014). "2.2". Sistemas operativos: Principios y práctica (2.ª ed.). Recursive Books. ISBN  978-0985673529.
  23. De Gelas, Johan. "Virtualización de hardware: los fundamentos" . AnandTech . Archivado del original el 4 de abril de 2010. Consultado el 13 de marzo de 2021 .
  • Manual de referencia del programador de Intel 80386

Lecturas adicionales

  • David T. Rogers (junio de 2003). Un marco para la subversión dinámica (PDF) (MSc). Escuela Naval de Posgrado . hdl : 10945/919 .
  • William J. Caelli (2002). "Reaprendiendo los "sistemas de confianza" en la era de NIIP: lecciones del pasado para el futuro" . Archivado del original (PDF) el 20 de abril de 2015.
  • Haruna R. Isa; William R. Shockley; Cynthia E. Irvine (mayo de 1999). "Una arquitectura de subprocesos múltiples para el procesamiento seguro de transacciones multinivel" (PDF) . Actas del Simposio IEEE de 1999 sobre Seguridad y Privacidad . Oakland, CA. págs. 166–179 . hdl : 10945/7198 . 
  • Ivan Kelly (8 de mayo de 2006). "Adaptación de MINIX a Xen" (PDF) . Archivado del original (PDF) el 27 de agosto de 2006.
  • Paul Barham; Boris Dragovic; Keir Fraser; Steven Hand; Tim Harris; Alex Ho; Rolf Neugebauer; Ian Pratt; Andrew Warfield (2003). "Xen y el arte de la virtualización" (PDF) .
  • Marco Peinado; Yuqun Chen; Pablo Inglaterra; Juan Manferdelli. "NGSCB: un sistema abierto confiable" (PDF) . Archivado desde el original (PDF) el 4 de marzo de 2005.
  • Michael D. Schroeder ; Jerome H. Saltzer (1972). "Una arquitectura de hardware para la implementación de anillos de protección" .
  • Manual del desarrollador de software de arquitectura Intel, volumen 3: Programación de sistemas (número de pedido 243192) (PDF) . Capítulo 4: «Protección»; sección 4.5: «Niveles de privilegio». Archivado del original (PDF) el 19 de febrero de 2009.
  • Tzi-cker Chiueh; Ganesh Venkitachalam; Prashant Pradhan (diciembre de 1999). «Integración de la segmentación y la protección de paginación para extensiones de software seguras, eficientes y transparentes». Actas del decimoséptimo simposio de la ACM sobre principios de sistemas operativos . Sección 3: Características de hardware de protección en la arquitectura Intel X86; subsección 3.1 Comprobaciones de protección. doi : 10.1145/319151.319161 . ISBN 1581131402. S2CID 9456119 . 
  • Takahiro Shinagawa; Kenji Kono; Takashi Masuda (17 de mayo de 2000). "Aprovechamiento del mecanismo de segmentación para la protección contra código móvil malicioso" (PDF) . Capítulo 3 Implementación; sección 3.2.1 Protección de anillo. Archivado del original (PDF) el 10 de agosto de 2017. Recuperado el 2 de abril de 2018 .
  • Boebert, William Earl; R. Kain (1985). Una alternativa práctica a las políticas de integridad jerárquicas . 8.ª Conferencia Nacional de Seguridad Informática.
  • Gorine, Andrei; Krivolapov, Alexander (mayo de 2008). "Bases de datos en modo kernel: una tecnología DBMS para aplicaciones de alto rendimiento" . Dr. Dobb's Journal .