Introducción a la arquitectura del sistema operativo Windows

---

La arquitectura del sistema Windows consta de los siguientes componentes:

1. Kernel: el kernel de Windows es la parte central del sistema operativo, responsable de tareas como la administración de los recursos del sistema, el manejo de las solicitudes de los programas y controladores del usuario y la coordinación de la comunicación entre varios componentes del sistema. El kernel de Windows se divide en modo de usuario y modo kernel. El modo kernel es un modo más seguro y de nivel superior, y los programas de usuario no pueden acceder directamente al modo kernel.

2. Controladores: los sistemas de Windows requieren muchos tipos diferentes de controladores para administrar los dispositivos de hardware y proporcionar la funcionalidad del sistema, como controladores de red, controladores de tarjetas de sonido, controladores de gráficos, etc. Estos controladores se ejecutan en modo kernel y pueden acceder a los recursos subyacentes y dispositivos de hardware del sistema.

3. Modo de usuario: El modo de usuario es el modo en que se ejecutan las aplicaciones en el sistema operativo Windows. En el modo de usuario, las aplicaciones pueden acceder a algunos recursos del sistema, como sistemas de archivos, redes, procesos y subprocesos, pero no pueden acceder directamente al modo kernel ni a los dispositivos de hardware subyacentes.

4. Subsistema Win32: El subsistema Win32 es una interfaz de programación de aplicaciones en el sistema operativo Windows que permite que las aplicaciones de 32 bits se ejecuten en el sistema operativo Windows. El subsistema Win32 proporciona una interfaz estándar para acceder a los recursos y funciones del sistema operativo, lo que permite que las aplicaciones se ejecuten en varios sistemas Windows.

5. API de Windows: La API de Windows es un conjunto de interfaces de programación de aplicaciones para acceder a diversos recursos y funciones del sistema operativo Windows. La API de Windows se puede utilizar en cualquier lenguaje de programación, incluidos C/C++, Java, Python y C#, entre otros.

6. Interfaz de usuario: la interfaz de usuario del sistema operativo Windows incluye componentes como el escritorio, la barra de tareas, ventanas, menús y cuadros de diálogo. Implementados a través de la API de Windows y el modo de usuario, estos componentes proporcionan los medios por los cuales el usuario interactúa y opera con el sistema operativo.

En términos generales, la arquitectura del sistema Windows es un sistema complejo que incluye múltiples componentes y modos, a través de los cuales estos componentes y modos trabajan juntos para proporcionar un entorno de sistema operativo estable, seguro y fácil de usar.

Aquí se presentará brevemente la arquitectura básica del sistema de Windows. Por el contenido de los capítulos anteriores, ya sabemos que Windows se divide en dos partes: modo usuario y modo kernel. Un diagrama esquemático simple es el siguiente:

Aquí puede ver un "monitor de máquina virtual" en la capa inferior, que también se ejecuta en modo kernel (RING-0), pero debido a que uso instrucciones especiales de CPU (VT-x, SVM), puede continuar monitoreando el kernel (o aplicación) mientras se aísla del kernel. Así que a menudo escuchamos el nombre Ring-1.

Los 4 tipos básicos de procesos en modo usuario

Aquí debemos presentar brevemente los cuatro procesos básicos de modo de usuario en el sistema operativo Windows:

• proceso de usuario
• proceso de servicio
• proceso del sistema
• Entorno Subsistema Servidor Proceso

proceso de usuario

Los procesos de usuario pueden ser de uno de los siguientes tipos:

• Un proceso de Windows de 32 o 64 bits (y en Windows 8 y versiones posteriores, aplicaciones de Windows que se ejecutan sobre Windows Runtime).
• proceso de 16 bits para Windows 3.1
• proceso de 16 bits para MS-DOS
• Procesos de 32 o 64 bits para POSIX

(Nota: los procesos de 16 bits solo pueden ejecutarse en Windows de 32 bits y Windows 8 ya no admite aplicaciones POSIX)

proceso de servicio

El proceso de servicio aloja servicios de Windows, como el Programador de tareas y los servicios de Cola de impresión.

Por lo general, los servicios deben poder ejecutarse sin que el usuario haya iniciado sesión, como lo hacen muchas aplicaciones de servidor de Windows. Los servicios como Microsoft SQL Server y Microsoft Exchange Server también contienen componentes que se ejecutan como servicios.

proceso del sistema

Los procesos del sistema son procesos estáticos o codificados, como procesos de inicio de sesión y administradores de sesión para servicios que no son de Windows. Es decir, estos procesos no los inicia el Administrador de control de servicios.

Proceso de servicio del subsistema de entorno

Los procesos de servicio del subsistema del entorno son aquellos que implementan las partes de soporte del entorno del sistema operativo.

El llamado "entorno" se refiere a la parte de personalización del sistema operativo que se presenta a los usuarios y programadores. Cuando Windows NT se lanzó por primera vez, proporcionó tres subsistemas ambientales: Windows, POSIX y OS/2. Pero el soporte para el subsistema OS/2 se detuvo después de Windows 2000 y el soporte para POSIX se detuvo después de Windows XP. Las ediciones de cliente y servidor de Windows 7 Ultimate y Enterprise de Windows 2008 R2 proporcionan un subsistema POSIX mejorado denominado Subsistema para aplicaciones basadas en UNIX (SUA). SUA ya no es compatible y ya no se incluye como una función opcional en Windows (ediciones de cliente o servidor).

Componentes del modo kernel de Windows

En Windows, las aplicaciones de usuario no pueden llamar directamente a los servicios del sistema operativo nativo de Windows, sino que necesitan llamar a través de una o más bibliotecas de vínculos dinámicos (DLL) del subsistema. La función de la DLL del subsistema es traducir las funciones documentadas en las correspondientes llamadas internas (a menudo no documentadas) de servicio del sistema nativo, que normalmente se implementan en Ntdll.dll. Esta conversión puede implicar o no el envío de mensajes al proceso del subsistema del entorno para dar servicio al proceso del usuario.

Los componentes del modo kernel de Windows son los siguientes:

• Ejecutor. El ejecutivo de Windows contiene los servicios básicos del sistema operativo, como administración de memoria, administración de procesos y subprocesos, seguridad, E/S, redes y comunicación entre procesos.
• Núcleo de Windows. El kernel de Windows contiene funciones del sistema operativo de bajo nivel, como la programación de subprocesos, el despacho de interrupciones y excepciones y la sincronización de multiprocesadores. El núcleo también proporciona una serie de rutinas y objetos básicos que otras partes del ejecutivo utilizan para implementar funciones de nivel superior.
• controlador de dispositivo. Los controladores de dispositivos incluyen controladores de dispositivos de hardware que traducen las llamadas de función de E/S del usuario en solicitudes de E/S para dispositivos de hardware específicos, así como controladores de dispositivos que no son de hardware, como controladores de sistema de archivos y de red.
• Capa de abstracción de hardware (HAL, capa de abstracción de hardware). Esta capa de código es responsable de aislar el kernel, los controladores de dispositivos y otras partes del ejecutivo de Windows de las diferencias específicas de la plataforma.
• Sistema de ventanas y gráficos. El sistema de ventanas y gráficos se utiliza para implementar funciones de interfaz de usuario (GUI) (también conocidas comúnmente como funciones GDI y USUARIO de Windows), como el manejo de ventanas, controles de interfaz de usuario y dibujo.
• Capa de hipervisor. Esta sección solo contiene el propio hipervisor. Esta sección no contiene otros controladores o módulos. Pero el hipervisor en sí está compuesto por varias capas internas y controladores, como su propio administrador de memoria, programador de procesador virtual, administración de interrupciones y temporizadores, rutinas de sincronización, administración de particiones (instancia de máquina virtual), comunicación entre particiones (IPC), etc.

componentes importantes del sistema

La estructura básica de Windows y los tipos de procesos comunes se mencionaron anteriormente, y el contenido de los componentes del sistema de Windows también se mencionó de manera incidental. La siguiente figura combina esta parte de los componentes del sistema para visualizar la arquitectura y los componentes del sistema principal de Windows.

En la figura anterior, podemos ver que varios componentes importantes del sistema en el entorno del sistema operativo Windows son:

1. Subsistemas ambientales y archivos DLL de subsistemas
2. otros subsistemas
3. Ejecutor
4. núcleo
5. capa de abstracción de hardware
6. controlador de dispositivo
7. proceso del sistema

La siguiente es una descripción detallada y una introducción del análisis de contenido anterior.

Subsistemas ambientales y archivos DLL de subsistemas

La función del subsistema de entorno es exponer algún subconjunto de los servicios básicos del sistema ejecutivo de Windows a las aplicaciones. Dichos subsistemas pueden acceder a un subconjunto diferente de servicios nativos de Windows. Esto significa que es posible que una aplicación creada en un subsistema no pueda hacer algo que sí puede hacer una aplicación creada en otro subsistema. Por ejemplo, las aplicaciones de Windows no pueden usar la función de bifurcación de SUA.

Cada imagen ejecutable (.exe) está vinculada a un subsistema único. Cuando la imagen se está ejecutando, el código responsable de crear el proceso verifica el código de tipo del subsistema en el encabezado de la imagen y luego notifica el nuevo proceso al subsistema correcto. Este tipo de código se puede especificar mediante la opción de vinculador /SUBSYSTEM en el comando de vinculación de Microsoft Visual Studio (o mediante la opción SubSystem de la página de propiedades del vinculador/sistema en las propiedades del proyecto).

Como se mencionó anteriormente, las aplicaciones de usuario no llaman directamente a los servicios del sistema de Windows, sino a través de una o más DLL de subsistema. Las interfaces exportadas por estas bibliotecas tienen la documentación correspondiente, y se pueden llamar los programas vinculados a los subsistemas correspondientes. Por ejemplo, las DLL del subsistema de Windows (como Kernel32.dll, Advapi32.dll, User32.dll y Gdi32.dll) implementan las funciones de la API de Windows y la DLL del subsistema SUA (Psxdll.dll) implementa las funciones de la API de SUA.

Aquí, puede usar la herramienta Dependency Walker (Dependency.exe) para ver el tipo de subsistema del archivo de imagen. (Sobre esta herramienta, puede consultar cómo descargarla y usarla mencionada en este artículo, https://blog.csdn.net/qq_37596943/article/details/131515390?spm=1001.2014.3001.5501 )

Verifique Notepad.exe y CMD.exe que vienen con el sistema operativo Windows respectivamente.

Como puede verse en las dos figuras anteriores, la DLL dependiente de Notepad.exe es completamente diferente de la DLL dependiente de CMD.exe. Y Notepad.exe dependerá de GDI32.DLL porque es una aplicación GUI, mientras que CMD.exe simplemente depende de la biblioteca NTDLL.DLL más básica.

Esto es lo que sucede cuando una aplicación llama a una función en un archivo DLL del subsistema:

• Las funciones se implementan completamente en modo usuario dentro de la DLL del subsistema. En otras palabras, no se envían mensajes al proceso del subsistema del entorno, ni se llama a ningún servicio del sistema ejecutivo de Windows. La función se ejecutará en modo de usuario y el resultado de la ejecución se devolverá a la persona que llama, como las funciones GetCurrentProcess y GetCurrentProcessId. (La ID de un proceso en ejecución no cambia, por lo que la ID se puede obtener desde alguna ubicación almacenada en caché para evitar llamadas al kernel).
• Una función requiere una o más llamadas al ejecutivo de Windows. Por ejemplo, las funciones ReadFile y WriteFile de Windows llaman a los servicios del sistema de E/S de Windows internos subyacentes (y no documentados para el uso en modo de usuario) NtReadFile y NtWriteFile, respectivamente.
• Una función para realizar algún trabajo en el proceso del subsistema de entorno. (El proceso del subsistema de entorno que se ejecuta en modo de usuario es responsable de mantener el estado de las aplicaciones cliente que se ejecutan bajo su control). En este caso, las solicitudes de cliente/servidor se envían al subsistema de entorno en forma de mensajes a través de ALPC, para que el subsistema pueda realizar la operación requerida. La DLL del subsistema luego espera una respuesta y se la devuelve a la persona que llama.

Algunas funciones se utilizarán en combinación con la segunda y la tercera anteriores, como las funciones CreateProcess y ExitWindowsEx de Windows.

Puesta en marcha del subsistema

El proceso del administrador de sesión (Smss.exe) inicia el subsistema. La información de inicio del subsistema se almacena en el registro bajo la clave HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems.

La clave requerida en la figura enumera los subsistemas cargados en el arranque del sistema. El valor consta de dos cadenas: Windows y Debug.

El valor de Windows contiene la especificación de archivo para el subsistema de Windows, donde Csrss.exe representa el subsistema de tiempo de ejecución cliente/servidor.

El valor Debug está vacío (este valor no es necesario desde Windows XP y la unidad permanece por compatibilidad), por lo que no tendrá efecto.

El valor opcional representa un subsistema opcional, que también está vacío en este ejemplo, porque Windows 10 ya no puede usar SUA. Lo que habría estado disponible sería apuntar un valor a través de POSIX a otro valor, que a su vez apunta a Psxss.exe (el proceso del subsistema POSIX). Los valores opcionales son todos "cargar a pedido", lo que significa que la imagen POSIX se cargará cuando la encuentre por primera vez. El valor del registro Kmode contiene el nombre de archivo de la parte del modo kernel del subsistema de Windows (Win32K.sys).

Subsistema de Windows

Si bien Windows fue diseñado para admitir múltiples subsistemas ambientales independientes, en realidad, hacer que cada subsistema implemente todo el código para manejar la ventana y mostrar la E/S crearía una gran cantidad de duplicación de funciones del sistema que, en última instancia, afectaría negativamente el tamaño y el rendimiento del sistema. Dado que Windows es el subsistema más importante, los diseñadores de Windows decidieron poner funciones básicas en el subsistema de Windows y dejar que otros subsistemas llamen al subsistema de Windows para lograr E/S de visualización, por lo que el subsistema SUA llama a los servicios en el subsistema de Windows para lograr E/S de visualización.

Como resultado de esta decisión de diseño, el subsistema de Windows se ha convertido en un componente obligatorio de cualquier sistema de Windows, incluso en sistemas de servidor que no brindan inicios de sesión de usuario interactivos. Entonces, este proceso también se convierte en un proceso crítico (si el proceso se cierra por algún motivo, el sistema fallará).

El subsistema de Windows consta de los siguientes componentes importantes:

1. Para cada sesión, una instancia del proceso Environment Subsystem (Csrss.exe) carga 4 DLL (Basesrv.dll, Winsrv.dll, Sxssrv.dll, Csrsrv.dll), lo que brinda soporte para:

• Diversas tareas administrativas relacionadas con la creación y eliminación de procesos y subprocesos
• Cierre de aplicaciones de Windows (a través de la API ExitWindowsEx)
• Contiene archivos .ini para asignaciones de ubicación de registro para mantener la compatibilidad con versiones anteriores
• Enviar determinados mensajes de notificación del kernel (como los del administrador Plug and Play) a las aplicaciones de Windows como mensajes de Windows (WM_DEVICECHANGE)
• Soporte parcial para procesos de máquina virtual para DOS (VDM) de 16 bits (solo Windows de 32 bits)
• Soporte para Side-by-Side (SxS)/Fusion y Manifest Caching
• Proporciona almacenamiento en caché para varias funciones de soporte de lenguaje natural

2. Un controlador de dispositivo en modo kernel (Win32k.sys) que proporciona la siguiente compatibilidad.

• administrador de ventanas Controla la visualización de ventanas, administra la salida de la pantalla, recopila entradas del teclado, el mouse y otros dispositivos, y pasa los mensajes del usuario a las aplicaciones.
• Interfaz de dispositivo gráfico (GDI). Esta es una biblioteca de funciones especialmente diseñada para dispositivos de salida de gráficos, que incluye funciones de dibujo relacionadas con líneas, texto y gráficos, así como funciones de control de gráficos.
• Funciones de envoltorio para la funcionalidad de DirectX. Esta es una función implementada por otro controlador en modo kernel (Dxgkrnl.sys).

3. Proceso de host de la consola (Conhost.exe), que se utiliza para proporcionar compatibilidad con aplicaciones de consola (interfaz de caracteres).
4. Desktop Window Manager (Dwm.exe), que genera una capa de superficie visible para las ventanas a través de CDD y DirectX.
5. DLL de subsistema (como Kernel32.dll, Advapi32.dll, User32.dll, Gdi32.dll) que traducen las funciones documentadas de la API de Windows en las correspondientes llamadas de servicio del sistema en modo kernel no documentadas (para el modo de usuario) en Ntoskrnl.exe y Win32k.sys.
6. Controlador de dispositivo gráfico. Se utiliza para proporcionar controladores de visualización de gráficos, controladores de impresora y controladores de minipuerto de video que dependen del hardware.

Windows 10 y Win32k.sys

Los requisitos de administración de ventanas más básicos para los dispositivos con Windows 10 dependen en gran medida del tipo de dispositivo específico, una computadora de escritorio completa que ejecute Windows debe tener todas las capacidades de administración de ventanas, como cambiar el tamaño de las ventanas, los propietarios de las ventanas, las ventanas secundarias, etc. Y Windows Mobile 10 que se ejecuta en un teléfono o una tableta pequeña no necesita tanto porque solo hay una ventana en primer plano que no se puede minimizar ni cambiar de tamaño. Lo mismo ocurre con los dispositivos IoT, que pueden ni siquiera necesitar una pantalla.

Por lo tanto, la funcionalidad de Win32K.sys se divide en varios módulos de kernel y es posible que algunos sistemas no requieran todos estos módulos. Esto reduce en gran medida la superficie de ataque del administrador de ventanas debido a la menor complejidad del código y elimina una gran cantidad de código heredado.

• En dispositivos móviles (Windows Mobile 10), Win32k.sys carga Win32kMin.sys y Win32kBase.sys
• En un sistema informático de escritorio completo, Win32k.sys carga Win32kBase.sys y Win32kFull.sys
• En algunos sistemas IoT, es posible que Win32k.sys solo necesite cargar Win32kBase.sys

Las aplicaciones necesitan llamar a funciones estándar de USUARIO para crear controles en la interfaz de usuario, como ventanas y botones, y mostrarlos en la pantalla. El administrador de ventanas pasa estas solicitudes a GDI, que las pasa al controlador del dispositivo gráfico, que realiza los ajustes necesarios junto con el dispositivo de visualización. Los controladores de pantalla se emparejan con los controladores de minipuerto de visualización para brindar compatibilidad con la visualización completa de video.

GDI proporciona un conjunto estándar de funciones bidimensionales que permiten que las aplicaciones se comuniquen con un dispositivo gráfico sin saber nada al respecto. Las funciones GDI se encuentran entre las aplicaciones y los dispositivos gráficos, como los controladores de pantalla y los controladores de impresora, y son responsables de interpretar las solicitudes de salida de imágenes de las aplicaciones y enviar las solicitudes a los controladores de pantalla gráfica. GDI también proporciona una interfaz estandarizada para aplicaciones que utilizan diferentes dispositivos de salida de gráficos. Con estas interfaces, el código de la aplicación puede permanecer independiente de los dispositivos de hardware y sus controladores. GDI también adapta el mensaje a las capacidades del dispositivo, normalmente dividiendo la solicitud en partes manejables. Por ejemplo, algunos dispositivos pueden comprender los comandos para dibujar una elipse y algunos dispositivos pueden requerir que GDI interprete los comandos como "una serie de píxeles colocados en una cierta posición de coordenadas".

Dado que la mayor parte del subsistema se ejecuta en modo kernel, solo unas pocas funciones de Windows necesitan enviar mensajes al proceso del Subsistema de Windows para la creación y terminación de procesos y subprocesos, asignación de letras de unidad de dispositivo DOS, etc.

otros subsistemas

Como se mencionó anteriormente, Windows admitió inicialmente los subsistemas POSIX y OS/2. Dado que el nuevo Windows no contiene estos subsistemas, no se describirá en detalle aquí.

Proveedor Pico y subsistema de Windows para Linux

Durante la última década más o menos, el modelo de subsistema tradicional ha brindado soporte para POSIX y OS / 2 con suficiente escalabilidad y capacidad.Sin embargo, dos limitaciones técnicas de este modelo dificultan su aplicación a una gama más amplia de binarios que no son de Windows y solo se pueden usar en algunos escenarios muy específicos.

Con el fin de solucionar una serie de problemas que deja la compatibilidad con POSIX bajo Windows. Windows ahora utiliza una nueva forma de crear subsistemas que elimina la necesidad de envolver en modo usuario tradicional las llamadas al sistema de otros entornos y la ejecución de imágenes PE tradicionales.

Este modelo define el concepto de un proveedor de Pico. Este es un controlador de modo de kernel personalizado que recibe acceso a una interfaz de kernel dedicada a través de la API PsRegisterPicoProvider. Esta interfaz dedicada trae muchos beneficios.

imagen primigenia

Use Dependency Walker para abrir Smss.exe (proceso del administrador de sesión), puede ver que solo depende de Ntdll.dll, y aquí muestra que su subsistema es nativo.

Ejecutor

El ejecutivo de Windows es la capa superior de Ntoskrnl.exe. (La capa inferior es el núcleo) El órgano ejecutivo contiene los siguientes tipos de funciones:

• Funciones que se pueden llamar desde cualquier lugar y desde el modo usuario. Estas funciones se denominan servicios del sistema y están disponibles en todas partes a través de Ntdll.dll.
• Una función de controlador de dispositivo llamada a través de DeviceIoControl. Esto proporciona una interfaz común para llamar a funciones en controladores de dispositivos desde el modo de usuario al modo kernel, lo que permite llamadas a funciones que no están relacionadas con operaciones de lectura/escritura.
• Una función a la que solo se puede llamar desde el modo kernel y se exporta y documenta en el WDK. Estas funciones contienen una variedad de rutinas de apoyo, como administrador de E/S, funciones ejecutivas generales (Ex), etc.
• Funciones que se exportan y llaman en modo kernel pero que no están documentadas en el WDK. Estas funciones incluyen funciones llamadas por el controlador de video de arranque, comenzando con Inbv.
• Una función definida como un símbolo global pero no exportable. Estas funciones incluyen funciones de soporte que se llaman internamente en Ntoskrnl.exe, como las que comienzan con Iop (funciones de soporte del administrador de E/S internas) o Mi (funciones de soporte de administración de la memoria interna).
• Una función dentro de un módulo pero no definida como un símbolo global. Estas funciones son ejecutivas y específicas del kernel.

Para los principales componentes del órgano ejecutivo, aquí hay una breve lista:

1. administrador de configuración
2. gestor de procesos
3. Monitor de referencia seguro
4. administrador de E/S
5. Administrador Plug and Play (PnP, Plug and Play)
6. administrador de energía
7. Modelo de controlador de Windows (WDM)
8. administrador de memoria
9. administrador de caché
10. administrador de objetos
11. Instalación LPC asíncrona (ALPC)
12. funciones de biblioteca en tiempo de ejecución
13. Rutinas de apoyo ejecutivo.

Además, se incluyen varias otras rutinas de infraestructura:

• Biblioteca de depuración en modo kernel.
• Marco de depuración de modo de usuario
• Biblioteca de hipervisor y biblioteca VBS
• Administrador de erratas
• Verificador de controlador
• Seguimiento de tiempo para Windows (ETW)
• Infraestructura de diagnóstico de Windows
• Arquitectura de errores de hardware de Windows
• tiempo de ejecución del sistema de archivos
• Motor de cuña del núcleo

núcleo

El kernel consta de una serie de funciones en Ntoskrnl.exe para proporcionar mecanismos básicos, como la programación de subprocesos y los servicios de sincronización utilizados por los ejecutables, y soporte independiente de la arquitectura de hardware subyacente. El código del núcleo está escrito principalmente en C, aunque el código ensamblador sigue utilizándose para tareas que requieren el uso de instrucciones especiales del procesador y registros a los que es difícil acceder en el código C.

Muchas funciones del kernel están documentadas en el WDK (busque funciones que comiencen con Ke) porque también son necesarias para las implementaciones de controladores de dispositivos.

objeto del núcleo

El kernel proporciona primitivos y mecanismos subyacentes bien definidos y predecibles del sistema operativo, que pueden ser utilizados por los componentes de alto nivel en el cuerpo ejecutivo para realizar las operaciones que necesitan.

Fuera del kernel, el cuerpo ejecutivo ve los hilos y otros recursos compartidos como objetos.

Hay un conjunto de objetos del kernel llamados objetos de control que establecen la semántica necesaria para controlar varias funciones del sistema operativo. Estos incluyen objetos de llamada a procedimiento asíncrono (APC), objetos de llamada a procedimiento diferido (DPC) y varios objetos utilizados por el administrador de E/S, como objetos de interrupción.

Otro conjunto de objetos del kernel llamados objetos de despachador contienen capacidades de sincronización que pueden cambiar o afectar la programación de subprocesos. Los objetos despachadores incluyen subprocesos del kernel, mutexes, tiempos, pares de eventos del kernel, semáforos, temporizadores y temporizadores de espera. El cuerpo ejecutivo utiliza las funciones del kernel para crear y mantener instancias de objetos del kernel, crear objetos más complejos y proporcionarlos al modo de usuario.

Región de control del procesador del kernel (KPCR) y bloque de control

El kernel utiliza una estructura de datos denominada Región de control del procesador del kernel (KPCR) para almacenar datos relacionados con el procesador. KPCR contiene información básica, como la tabla de distribución de interrupciones del procesador (Tabla de despacho de interrupciones, IDT), el segmento de estado de tareas (Segmento de estado de tareas, TSS) y la tabla de descriptores globales (Tabla de descriptores globales, GDT).

KPCR también contiene el estado del controlador de interrupción, que se comparte con otros módulos (ACPI, HAL).

El KPCR también contiene una estructura de datos incrustada llamada Bloque de control del procesador del kernel (KPRCB). Para el uso de controladores de terceros y otros componentes internos del kernel de Windows, KPCR es una estructura de datos documentada, mientras que KPCB es una estructura privada utilizada exclusivamente por el código del kernel en Ntoskrnl.exe, que contiene lo siguiente:

• Información de programación. Como el subproceso actual que se está programando en el procesador, el siguiente subproceso en ejecución y el subproceso inactivo
• La base de datos del distribuidor del procesador. que contiene una cola lista para cada prioridad
• cola de DPC
• Proveedor de CPU e información de identificador, como modelo, pasos, velocidad, banderas
• Topologías de CPU y NUMA. Como información de nodo, número de núcleos por chip, número de procesadores lógicos por núcleo, etc.
• tamaño del caché
• Información de conteo de tiempo como DPC y tiempo de interrupción.

Puede usar !prcb para ver la dirección y la información de datos de PRCB a través de windbg

soporte de hardware

Otro trabajo importante del kernel es abstraer o abstraer a los ejecutivos y controladores de dispositivos de las diferencias en las diferentes arquitecturas de hardware compatibles con Windows.Este trabajo también incluye el manejo de las diferencias entre varias funciones, como el manejo de interrupciones, el envío de excepciones y la sincronización del procesador.

capa de abstracción de hardware

La capa de abstracción de hardware (HAL) es la clave para la portabilidad. HAL es un módulo de modo kernel cargable (Hal.dll) que proporciona una interfaz de bajo nivel para las plataformas de hardware que ejecutan Windows. Puede ocultar detalles relacionados con hardware específico, como interfaces de E/S, controladores de interrupción, mecanismos de comunicación multiprocesador y funciones relacionadas con arquitecturas y computadoras específicas.

Muchas rutinas HAL se introducen en WDK, puede consultar la documentación de WDK para obtener más detalles. Los módulos específicos se describen a continuación:

Nombre de archivo HAL	sistema compatible
Halacpi.dll	Equipo de configuración avanzada e interfaz de energía (ACPI), lo que implica que solo hay un procesador y no es compatible con APIC (controlador de interrupciones). Si no se cumple alguna de las dos condiciones, use el siguiente HAL
Halmacpi.dll	Computadoras con controlador de interrupción programable avanzado (APIC) que admiten ACPI, usar un APIC también significa admitir SMP

Aquí puede usar la herramienta Dependency Walker para ver las dependencias de Ntoskrnl.exe.

Se pueden ver varias de las bibliotecas DLL.

• PSHED.DLL. Un controlador de errores de hardware específico de la plataforma (PSHED) proporciona una abstracción para las capacidades de informes de errores de hardware de la plataforma subyacente. Esto se logra ocultando los mecanismos de manejo de errores de la plataforma del sistema operativo y exponiendo una interfaz consistente al sistema operativo Windows.
• BOOTVID.DLL. El controlador de video de inicio (Boorvid) en los sistemas X86 brinda soporte para los comandos VGA necesarios para mostrar el texto de inicio y los logotipos de inicio durante el inicio del sistema.
• KDCOM.DLL. Biblioteca de comunicación del protocolo de depuración (KD) en modo kernel.
• CI.DLL. biblioteca de integridad
• MSRPC.SYS. Un controlador de cliente delgado de llamada a procedimiento remoto (RPC) para el modo kernel que permite que el kernel (y otros controladores) se comuniquen con los servicios en modo usuario a través de RPC, o para administrar recursos para el código MES.

controlador de dispositivo

Un controlador de dispositivo es un módulo de modo kernel cargable (su archivo generalmente tiene una extensión .sys) que establece una interfaz entre el administrador de E/S y el hardware asociado. Un controlador de dispositivo se ejecuta en modo kernel usando uno de los siguientes tres contextos.

1. En el contexto de un subproceso de usuario que inicia una función de E/S (como una operación de lectura)
2. En el contexto de un subproceso del sistema en modo kernel (como una solicitud iniciada por el administrador Plug and Play)
3. No en ningún contexto de subproceso en particular como resultado de una interrupción, sino en el contexto de subproceso "actual" cuando ocurrió la interrupción.

El controlador de dispositivo de Windows no opera directamente el hardware, sino que llama a las funciones en HAL para interactuar con el hardware. Los controladores suelen estar escritos en C o C++, por lo que el uso adecuado de las rutinas HAL permite la portabilidad a nivel de fuente entre diferentes arquitecturas de CPU compatibles con Windows y la portabilidad binaria dentro de la misma familia de arquitectura.

Los controladores de dispositivos incluyen principalmente los siguientes tipos:

• Controladores de dispositivos de hardware. Use la HAL para manipular el hardware para escribir la salida o tomar la entrada de un dispositivo físico o una red. Los controladores de dispositivos de hardware incluyen muchos tipos, como controladores de bus, controladores de interfaz hombre-máquina, controladores de dispositivos de almacenamiento masivo, etc.
• Controlador del sistema de archivos. Un controlador de Windows que toma una solicitud de E/S orientada a archivos y la traduce en una solicitud de E/S específica del dispositivo.
• Controlador de filtro del sistema de archivos. Incluye controladores que realizan la duplicación y el cifrado del disco, escanean en busca de virus, interceptan solicitudes de E/S y realizan procesamiento adicional antes de pasar la E/S a la siguiente capa.
• Redirección de red y servidores. Este controlador del sistema de archivos es responsable de pasar las solicitudes de E/S del sistema de archivos a otras computadoras en la red, o de recibir solicitudes de otras computadoras a través de la red, respectivamente.
• controlador de protocolo Responsable de implementar protocolos de red como TCP/IP, NetBEUI e IPX/SPX.
• Controlador de filtro de transmisión de kernel. Dichos controladores están conectados entre sí para realizar el procesamiento de señales en el flujo de datos, como grabar o reproducir audio y video.
• controladores de software Dicho módulo kernel realizará operaciones que solo se pueden realizar en modo kernel en nombre de algún proceso en modo usuario.

Modelo de controlador de Windows

El controlador original de Windows se creó en la primera versión del sistema NT (3.1), pero debido a razones de Plug and Play (PnP) (los controladores NT no son compatibles con PnP), continuó hasta que se lanzó Windows 2000 para admitir controladores PnP, a través de WDM El modelo de controlador (modelo de controlador de Windows, WDM) es compatible con PnP y compatibilidad con opciones de energía. Hasta ahora, WDM se ha conservado después de muchas actualizaciones y se ha convertido en el modelo básico para escribir controladores de hardware para Windows 2000 y versiones posteriores.

Los modelos de controladores WDM se pueden dividir en tres tipos:

1. conductor de autobús. Sirve controladores de bus, adaptadores, puentes o cualquier dispositivo con subdispositivos. Hay un conductor de autobús para cada tipo de autobús en el sistema. Los proveedores de terceros pueden escribir controladores de bus para proporcionar compatibilidad con nuevos tipos de bus, como VMEbus, Multibus y Futurebus.
2. Controlador de funciones. Es el controlador de dispositivo más importante, que proporciona una interfaz operativa para el dispositivo correspondiente. A menos que el dispositivo se ejecute en modo sin procesar (RAW) (la E/S se realiza mediante controladores de bus y filtros de bus juntos), el controlador de función es el controlador requerido para el dispositivo y, por lo general, el único controlador que puede acceder a los registros asociados con el dispositivo.
3. controlador de filtro Los controladores de filtro se pueden usar para agregar funcionalidad adicional a un dispositivo o a una secuencia de controlador existente. O modifique las solicitudes de E/S o las respuestas de otros controladores. Normalmente se utiliza para reparar dispositivos de hardware que no proporcionan correctamente información sobre los requisitos de recursos de hardware. Los controladores de filtro son opcionales y pueden existir en cualquier número por encima o por debajo de los controladores de funciones. Los controladores de filtro generalmente los proporciona el fabricante del equipo original (OEM) del sistema o el proveedor de hardware independiente (IHV).

En un entorno de controlador WDM, ningún controlador individual puede controlar todos los aspectos de un dispositivo. El controlador de bus es responsable de informar los dispositivos conectados al bus al administrador de PnP, y el controlador de funciones es responsable de operar los dispositivos.

Conceptos básicos del controlador de Windows

Windows Driver Foundation (Fundación de controladores de Windows, WDF) proporciona un marco de controlador de modo kernel (marco de controlador de modo kernel, KMDF) y un marco de controlador de modo de usuario (marco de controlador de modo de usuario, UMDF). Estos dos marcos simplifican el desarrollo de controladores de Windows.

KMDF proporciona una interfaz WDM más simplificada y oculta la complejidad del proceso de desarrollo del controlador sin cambiar los modelos subyacentes de bus, bus y filtro. Un controlador KMDF responde a las cosas con las que puede registrarse y llama a la biblioteca KMDF para realizar varios trabajos que no son específicos del dispositivo que administra, como la administración general de energía y la sincronización. En algunos casos, una sola llamada de función KMDF puede reemplazar una gran cantidad de código WDM para implementar la operación.

UMDF habilita controladores en modo de usuario para ciertos tipos de dispositivos (principalmente dispositivos USB u otros buses de protocolo de alta latencia, como cámaras de video, reproductores de MP3, teléfonos celulares, impresoras, etc.). Esencialmente, UMDF ejecuta cada controlador en modo usuario como un servicio en modo usuario y usa ALPC para comunicarse con el controlador contenedor que se ejecuta en modo kernel para acceder realmente al hardware. Si el controlador UMDF falla, el proceso "muere" y generalmente se reinicia. Esto no hará que el sistema deje de ser confiable, el único costo es que el dispositivo no esté disponible temporalmente mientras el servidor del servicio reinicia el controlador.

Controlador universal de Windows

A partir de Windows 10, puede usar el controlador universal de Windows (controlador universal de Windows, UWD) para usar la API compartida y la interfaz de controlador de dispositivo (interfaz de controlador de dispositivo, DDI) proporcionada por el kernel universal de Windows 10 para realizar "escribir una vez, ejecutar en todas partes" del controlador. Este tipo de controlador puede lograr compatibilidad binaria para una arquitectura de CPU específica y se puede usar en diferentes formas de dispositivos, incluidos dispositivos IoT, teléfonos móviles, HoloLens, Xbox one y computadoras portátiles. Los controladores universales de Windows pueden usar KMDF, UMDF 2.x o WDM como modelo de controlador.

Puede usar Msinfo32.exe para verificar los controladores de dispositivo instalados.

En la figura se puede ver que podemos encontrar el controlador de dispositivo actualmente instalado aquí, y también mostrar la ubicación del archivo del controlador correspondiente al controlador y el estado del servicio actual.

Cuando iniciamos manualmente el servicio, también podemos ver que ahora se está ejecutando.

También puede usar la herramienta Explorador de procesos para ver los controladores de dispositivos cargados actualmente a través del proceso del sistema.

proceso del sistema

Cada sistema Windows 10 contiene algunos procesos de sistema especiales. No ejecutan ejecutables en modo de usuario; estos procesos se denominan procesos mínimos. (Ejemplo: inactivo, sistema, sistema seguro, compresión de memoria)

• Proceso inactivo. Contiene un subproceso por CPU para ocupar el tiempo de inactividad de la CPU
• proceso del sistema. Contiene la mayoría de los hilos y identificadores del sistema en modo kernel
• proceso de sistema seguro. Contiene el espacio de direcciones del kernel seguro bajo VTL1
• proceso de compresión de memoria. Contiene la carga de trabajo comprimida de los procesos en modo usuario
• Administrador de sesión (Smss.exe)
• Subsistema de Windows (Csrss.exe)
• Inicialización de la sesión 0 (Wininit.exe)
• El proceso de inicio de sesión (Winlogon.exe)
• Administrador de control de servicios (services.exe) y sus procesos de servicio secundarios creados, como el proceso de host de servicio regular (Svchost.exe) proporcionado por el sistema
• Servicio de autenticación de seguridad local (Lsass.exe) y servidor de autenticación de seguridad local (Lsaiso.exe) aislados después de habilitar Credential Guard

Puede ver el árbol de procesos abriendo la herramienta Explorador de procesos para saber quién creó los procesos anteriores, lo que es útil para comprender el origen de cada proceso.

apéndice

Significado de nombres de interfaz API de uso común

Los prefijos de nombre de la mayoría de las funciones comúnmente utilizadas por los componentes ejecutivos de Windows tienen ciertos significados. Por ejemplo, la primera letra del prefijo va seguida de i (para interno), y el prefijo completo va seguido de la letra p (para privado). Los comunes son los siguientes:

prefijo	componentes
alpc	llamada de procedimiento local avanzado, llamada de procedimiento local avanzado
CC	caché pública, caché común
Cm	administrador de configuración, administrador de configuración
DBG	Soporte de depuración de kernel, soporte de depuración de kernel
dbgk	Marco de depuración de modo de usuario, marco de depuración para modo de usuario
em	gestor de erratas, gestor de erratas
algo	Seguimiento de eventos de Windows, seguimiento de eventos para Windows
Ex	Rutina de apoyo ejecutivo, rutina de apoyo ejecutivo
FsRtl	biblioteca de tiempo de ejecución del sistema de archivos, biblioteca de tiempo de ejecución del sistema de archivos
alto	biblioteca colmena, biblioteca colmena
Hvl	biblioteca de hipervisor
yo	administrador de E/S
Kd	depurador de modo kernel, depurador de kernel
Cuando	núcleo
Señor	Motor de corrección del núcleo, motor de corrección del núcleo
lsa	autoridad de seguridad local autoridad de seguridad local
mmm	administrador de memoria, administrador de memoria
Nuevo Testamento	Servicio del sistema NT, servicio del sistema NT, accesible a través de llamadas al sistema en modo de usuario
Transmisión exterior	administrador de objetos
P.f.	Prelector, Prefetchr
Después	administrador de energía, administrador de energía
PoFx	marco de poder, marco de poder
Páginas	Gerente de PnP, gerente de PnP
ppm	administrador de energía del procesador, administrador de energía del procesador
PD	Soporte de proceso, soporte de proceso
derecho	Biblioteca de tiempo de ejecución, Biblioteca de tiempo de ejecución
Se	monitor de referencia de seguridad, monitor de referencia de seguridad
pequeño	gerente de la tienda
Tm	administrador de transacciones
Ttm	administrador de tiempo de espera de terminal, administrador de tiempo de espera de terminal
v.f.	verificador de controlador, verificador de controlador
vsl	biblioteca de modo seguro virtual, biblioteca de modo seguro virtual
wdi	Infraestructura de diagnóstico de Windows, Infraestructura de diagnóstico de Windows
Wfp	Huella digital de Windows, Huella digital de Windows
Dónde	Arquitectura de error de hardware de Windows, arquitectura de error de hardware de Windows
Wmi	Instrumentación de Administración Windows
Zw	Espejo del punto de entrada del servicio del sistema, que puede establecer el modo de acceso anterior al modo kernel.

En general, la convención de nomenclatura para las rutinas de Windows es la siguiente:

<Prefix><Operation><Object>

Resumen del contenido principal de este artículo