Cómo salta Windows entre anillos (Modo Kernel y modo Usuario)

Esta semana estamos de fiesta, y es que una de mis pasiones en el desarrollo siempre ha sido verle las tripas a Windows, y a ello vamos. Antes de nada, lo que voy a contar aquí es un resumen del punto System Service Dispatching del capítulo 3 de Windows Internals 5ª edición, pero es un resumen un poco especial porque voy a añadir cosas de mi cosecha, como siempre hago, ya que no es cosa de ir parafraseando lo que voy aprendiendo/recordando.

En entradas anteriores, y algunas veces en los foros, he comentado sobre saltos entre anillo 0 y anillo 3, y aquí voy a explicar de pasada lo que significa. Un microprocesador moderno (y no tan moderno), cuenta con un juego de instrucciones en cierta medida especiales, instrucciones que son necesarias para configurar el hardware y el propio funcionamiento del software. Hablamos aquí de las interrupciones y toda su parafernalia asociada, del control de la memoria virtual, del acceso directo a hardware (es decir, escribir o leer en una dirección de memoria o en un puerto en el que no hay tal, sino alguna electrónica que debe reaccionar en base a dicha lectura o escritura), etc.

Esas instrucciones son peligrosas de usar, y en general no deben estar disponibles para los programas normales, ya que entonces un error podría llevar a la caída total del sistema o incluso a la rotura de algún elemento electrónico.

Es decir, que podríamos dividir el juego de instrucciones de un microprocesador en dos grandes grupos: aquellas que no son necesarias para que un programa funcione normalmente y las que, si se usan de forma incorrecta, pueden terminar armando un buen pirifostio.

Pues básicamente eso son los anillos 0 y 3. En el 0 están las instrucciones peligrosas, en el 3 las que cualquier programa puede usar, y si un programa normal utiliza una del cero, generará una excepción (¿De qué me sonará esto?) que será capturada por el sistema operativo y manejada a su antojo. Aunque realmente no es del todo así, para nuestro propósito es suficiente.

(Si os dais cuenta, he hablado del 0 y del 3, pero también hay un 1 y un 2, que Windows no utiliza. Digamos que la separación de las instrucciones en estos distintos niveles permiten una serie de facilidades a la hora de construir software de sistemas, ya sean sistemas operativos o aplicaciones que vayan a correr en un microprocesador con estas características, lo que ocurre es que Windows aprovecha estos niveles únicamente de una sola forma, que llama modo usuario y modo kernel).

Pues bien, el kelmer, uis, perdón, el kernel, la mayoría de los drivers, y el motor gráfico (que fue ampliamente criticado en su momento pero que permitió que NT 4.0 pudiera ser usado en ordenadores no tan potentes) se ejecutan en el anillo 0, y los demás subsistemas (incluido Win32) en el 3. De esta forma un programador chapucero (o un compilador) sólo podrá tumbar su programa y nada más. Recordemos los días de Windows 3.x y DOS en los cuales tumbar por completo el sistema era tan fácil como ejecutar dos instrucciones de ensamblador seguidas: cli y luego sti, o al revés, ya no me acuerdo.

Una aplicación llama a una función, que debe terminar siendo ejecutada dentro del kernel (por ejemplo, abrir y leer de un fichero, cosa que necesita que los drivers de disco hagan trabajo de bajo nivel sobre la controladora y sobre el propio disco). Pongamos que nuestro programa llama a WriteFile(), y nos da igual que sea una aplicación .NET llamando a sus clases, ya que terminará en esa función. Esa función, que está en Kernel32.dll y pertenece al subsistema Win32, llamará a NtWriteFile(), que está en Ntdll.dll y no pertenece a ningún subsistema, sino que está disponible para cualquiera de ellos. Esta función llamará entonces a KiSystemService(), que está en Ntoskrnl.exe y se ejecuta en el anillo 0 en lugar del 3. Finalmente, esta última función hará lo que tenga que hacer llamando a otras funciones del kernel y de los drivers hasta que al final devolverá el resultado hacia atrás hasta nuestra aplicación.

Fácil, ¿no? Pues no, porque si nuestra aplicación hubiera llamado a WriteFile() con algún parámetro mal que fuera crítico (y se me ocurre pasar un valor aleatorio diferente de cero al handle del fichero sobre el que queremos escribir), lo más seguro es que termináramos en una pantalla azul (como más o menos ocurría en Windows 3.x y a veces en Windows 9x). Además, es muy posible que durante el procesamiento de la función, se salte varias veces entre el modo kernel y el user por necesidades del guión.

Pero todavía hay más, ya que no hemos tenido en cuenta que el controlador de tiempos y de procesos puede cortar en cualquier momento esa llamada para atender otros procesos o incluso hilos de nuestra aplicación. Vamos, que no es fácil ni de lejos.

¿Cómo se produce el salto entre el anillo 3 y el 0, que hemos descrito más arriba? Pues depende del procesador que estemos usando. En la época de Windows 9x (y de la parte en modo protegido de Windows 3.x cuando la había), y para micros antiguos, NtWriteFile(), después de verificar que los parámetros recibidos son correctos, coloca en varios registros del procesador lo necesario, y ejecuta la instrucción int 0x2e, que genera una excepción si se hace desde el anillo 3. Esta excepción es recogida por el Kernel, que mediante los parámetros que hay en los registros determina si es una petición válida (y si no lo es protestará) y la procesará mediante la ejecución de la función correspondiente situada en un array de punteros a función que se llama System Service Dispatch Table, de las que creo que hay varias. Básicamente, lo que está haciendo es recibir un índice que se corresponde a una posición dentro del array de punteros, y como nos equivoquemos con esto la hemos cagado a base de bien, y es por eso por lo que antes del salto entre anillos se verifican los parámetros. El retorno al anillo 3 se produce con la ejecución de la instrucción iretd.

En micros Intel más modernos, el salto se hace mediante la instrucción sysenter y la vuelta mediante sysexit (o iret si estamos en modo depuración). En un AMD las instrucciones son syscall y sysret.

Y finalmente, en micros de 64 bits con la arquitectura x64 las instrucciones son las mismas que en el AMD (por que fueron los primeros en implementarla) y en la I64, epc.

Si os dais cuenta, dependiendo del microprocesador se hace de una u otra forma, lo que puede ser un serio quebradero de cabeza. Lo que hace Windows al arrancar un sistema de 32 bits es instalar la instrucción correcta en una posición de memoria y juego ejecutar sobre ella, con lo que a lo anterior añadimos un nuevo nivel de indirección.

La secuencia completa de paso del anillo 3 al 0 consiste, más o menos, en lo siguiente: primero se verifican los parámetros recibidos de la forma más completa posible, luego se ejecuta la instrucción que hay en cierta posición de memoria, que a su vez generará una excepción, que será controlada por el sistema operativo, que mirará si los parámetros son correctos, y si lo son volverá a saltar sobre un puntero a puntero a función, y finalmente lo que haya allí hará el trabajo.

Eso para un solo salto. Imaginaros cuántos son necesarios para que nuestro programa, y el sistema operativo funcione. Y no hemos hablado de que en cada una de esos pasos es necesario que la pila se guarde o se recupere, y que los datos deben ser copiados desde la pila de modo user a la de modo kernel para evitar que la aplicación pueda modificarlos en medio de una operación interna…

En un sistema x64 la operación es algo más sencilla porque la instrucción de salto es siempre la misma y no es necesaria la indirección extra sobre la instrucción ya que da igual que el microprocesador sea un Intel o un AMD.

Esto quizás te presente una duda en el caso de equipos de 32 bits: ¿por qué no está cableada dicha instrucción y simplemente a la hora de instalar Windows o de arrancarlo, el cargador pone en memoria el juego de DLLs correcto? Pues realmente no tengo ni idea, lo que sí tengo claro es que en ese caso Windows debería contar con al menos 4 juegos completos de DLLs y o bien elegir el necesario durante la instalación o casi cuadriplicar el espacio ocupado en disco. Lo que sí es cierto es que si se hubiera hecho así, el Windows de 32 bits funcionaría sensiblemente más rápido… o no.

Sólo nos queda ver, por mor de completitud, cómo funciona internamente el kernel sobre sí mismo. Supongamos por un momento que el kernel necesita acceder a la funcionalidad que hay en WriteFile(), pero en lugar de llamar a esta función directamente, lo que hace es llamar directamente a la rutina a la que se está apuntando en la tabla SSDT y santas pascuas, ya que en principio no se necesita verificar los parámetros que se suponen son correctos, y aparte de eso ya estamos en el anillo 0. No obstante, un driver no puede hacerlo así porque Microsoft no se fía de ellos, y es por ello que existen unas funciones que tiene como prefijo Zw y que son las que llamarán a su homónimo apuntado por la SSDT después de realizar las verificaciones –menos que si se llamara desde el anillo 3- oportunas.

5 comentarios sobre “Cómo salta Windows entre anillos (Modo Kernel y modo Usuario)”

  1. Siempre me había preguntado cómo una línea en un lengaje d eprogramación es convertida y transformada para que le diga al cabezal del disco duro que escriba en el sector correcto, o cómo sabe la tarjeta de video qué área ocupa una ventana y ordenarle al monitor (si es un crt) que haga el barrido de tal forma que muestre los píxeles de los colores correctos, y cómo el sistema operativo sabe dónde está el puntero del mouse (por defecto al inicio lo coloca al centro de la pantalla), o cómo hace para diibujar en la pantalla una ventana, ya que usando win32asm no se tiene acceso a las instrucciones en asm que determinan el color gris de la ventana, las sombritas, etc.

    Arg! sí que es complicado cuando empiezas a buscar cómo funcionan los programas en el nivel más profundo (allí, donde reina la mecánica cuántica…)

  2. Ohhhh, aquellos tiempos de CS, DS, Push, Pop, escrituras directas a la memoria de video, los .COM. MASM, TASM, el viejo ensamblador.
    Me gustaba mucho aquello pero todo continua, hay que evolucionar.

  3. Solo comentaros que los anillos 1 y 2 se están usando para virtualización. El anillo 1 para modo kernel y el anillo 2 para modo usuario dentro de una máquina virtual.

  4. < Esas instrucciones son peligrosas de usar, y en general no deben estar disponibles para los programas normales, ya que entonces un error podría llevar a la caída total del sistema o incluso a la rotura de algún elemento electrónico.> Este comentario aunque viejo resalto que el autor desconoce totalmente la parte electrónica de un PC. Venir a decir que con software se produce una rotura de un elemento electrónico es de desconocedor total del tema, está claro que cada cual con su especialidad casi siempre el informático salta los límites de sus posibilidades adentrándose en la parte electrónica desconociéndola totalmente y cometiendo errores en sus comentarios que desbarata todo bien dicho anteriormente

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *