Requisitos del controlador ELAM

La instalación del controlador debe usar las herramientas existentes para la instalación en línea y sin conexión, registrando un controlador a través del procesamiento INF típico. Para obtener código de controlador ELAM de ejemplo, consulte lo siguiente: https://github.com/Microsoft/Windows-driver-samples/tree/main/security/elam

Instalación del controlador AM

Para garantizar la compatibilidad de instalación del controlador, un controlador ELAM se anuncia como un controlador de arranque similar a todos los demás controladores de arranque. INF establece el tipo de inicio en SERVICE_BOOT_START (0), lo que indica que el cargador de arranque debe cargar el controlador e inicializarse durante la inicialización del kernel. Un controlador ELAM anuncia su grupo como "Early-Launch". El comportamiento de inicio temprano para los controladores de este grupo se implementará en Windows, tal como se describe en la sección siguiente.

A continuación, se muestra un ejemplo de la sección de instalación del controlador ELAM en un archivo INF.

[SampleAV.Service]
DisplayName    = %SampleAVServiceName%
Description    = %SampleAVServiceDescription%
ServiceType    = 1       ; SERVICE_KERNEL_DRIVER
StartType      = 0       ; SERVICE_BOOT_START
ErrorControl   = 3       ; SERVICE_ERROR_CRITICAL
LoadOrderGroup = “Early-Launch”

Dado que un controlador AM no posee ningún dispositivo, es necesario instalar el controlador AM en modo heredado, de modo que el controlador solo se agregue como un servicio al registro. (Si el controlador AM se instala como un controlador PNP normal, se agregará a la sección de enumeración del registro y, por tanto, tendrá una referencia de PDO, lo que provocará un comportamiento no deseado al descargar el controlador).

También debe incluir una sección SignatureAttributes en el archivo INF para el controlador ELAM.

Instalación del controlador de copia de seguridad

Para proporcionar un mecanismo de recuperación en caso de que el controlador ELAM esté dañado accidentalmente, el instalador de ELAM también instala una copia del controlador en una ubicación de copia de seguridad. Esto permitirá a WinRE recuperar la copia limpia y recuperar la instalación.

El instalador lee la ubicación del archivo de copia de seguridad de la clave BackupPath almacenada en

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\EarlyLaunch

A continuación, el instalador coloca la copia de seguridad en la carpeta especificada en la clave regkey.

Inicialización del controlador AM

El cargador de arranque de Windows, Winload, carga todos los controladores de arranque y sus archivos DLL dependientes en la memoria antes de transferir el control al núcleo de Windows. Los controladores de arranque representan los controladores de dispositivo que deben inicializarse antes de inicializar la pila de discos. Estos controladores incluyen, entre otros, la pila de discos y el administrador de volúmenes, y los controladores del sistema de archivos y los controladores de bus para el dispositivo del sistema operativo.

Interfaz de devolución de llamada del controlador AM

Los controladores ELAM usan callbacks para proporcionar al administrador PnP una descripción de cada controlador de arranque y DLL dependiente, y pueden clasificar todas las imágenes de arranque como un binario correcto conocido, un binario incorrecto conocido o un binario desconocido.

La política predeterminada del sistema operativo es no inicializar controladores y archivos DLL conocidos como malos. La directiva se puede configurar y se mide mediante Winload como parte de la atestación de arranque.

PnP utiliza la política y la clasificación proporcionada por el controlador AM para decidir si se debe inicializar cada imagen de arranque.

Devoluciones de llamada del Registro

Los controladores de Inicio temprano pueden usar callbacks del registro o de controladores de arranque para supervisar y validar los datos de configuración usados como entrada para cada controlador de inicio. Los datos de configuración se almacenan en la rama del registro del sistema, que es cargada por Winload y está disponible durante la inicialización del controlador de arranque.

Estas devoluciones de llamada son válidas durante la duración del controlador ELAM y se desregistrarán cuando se descargue el controlador. Para más información, vea:

• CmRegisterCallbackEx
• CmRegisterCallback
• CmUnRegisterCallback

Callbacks del controlador de arranque

Use IoRegisterBootDriverCallback e IoUnRegisterBootDriverCallback para registrar y anular el registro de un BOOT_DRIVER_CALLBACK_FUNCTION.

Esta devolución de llamada proporciona actualizaciones de estado de Windows a un controlador ELAM, incluido cuando se han inicializado todos los controladores de arranque y la instalación de devolución de llamada ya no es funcional.

Tipo de devolución de llamada

La enumeración BDCB_CALLBACK_TYPE describen dos tipos de callbacks:

• Funciones de retorno que proporcionan actualizaciones de estado a un controlador de ELAM (BdCbStatusUpdate)
• Devoluciones de llamada usadas por el controlador AM para clasificar los controladores de arranque y los archivos DLL dependientes antes de inicializar sus imágenes (BdCbInitializeImage)

Los dos tipos de devolución de llamada tienen estructuras de contexto únicas que proporcionan información adicional específica de la devolución de llamada.

La estructura de contexto de la devolución de llamada de actualización de estado contiene un único tipo enumerado que describe la llamada de Windows.

La estructura del contexto para la llamada de retorno de imagen de inicialización es más compleja, conteniendo información de hash y certificado para cada imagen cargada. La estructura contiene además un campo que es un parámetro de salida, donde el controlador AM almacena el tipo de clasificación relacionado con el controlador.

Un error devuelto de una callback de actualización de estado se trata como un error fatal y provoca una verificación de errores del sistema. Esto proporciona a un controlador ELAM la capacidad de indicar cuándo se llega a un estado fuera de la directiva de AM. Por ejemplo, si un controlador en tiempo de ejecución de AM no se cargó e inicializó, el controlador Early Launch puede fallar en la devolución de llamada para preparar la descarga a fin de evitar que Windows entre en un estado sin que se haya cargado un controlador AM.

Una imagen se trata como desconocida cuando se devuelve un error desde la función de inicialización de la imagen. Los controladores no identificados se inicializan o se omite su inicialización en función de la política del sistema operativo.

Firmas de malware

Los datos de firma de malware están determinados por el ISV de AM, pero deben incluir, como mínimo, una lista aprobada de hashes de controladores. Los datos de la firma se almacenan en el registro en un nuevo subárbol "Controladores de Lanzamiento Temprano" bajo HKLM que es cargado por Winload. Cada controlador AM tiene una clave única en la que almacenar su objeto binario grande (BLOB) de firma. La ruta de acceso y la clave del Registro tienen el formato :

HKLM\ELAM\<VendorName>\

Dentro de la clave, el proveedor es libre de definir y usar cualquiera de los valores. Hay tres valores de blob binarios definidos que se miden mediante el arranque medido y el proveedor puede usar cada uno:

• Medido
• Política
• Configuración

La colmena de ELAM se descarga después de ser utilizada por Early Launch Antimalware para mantener el rendimiento. Si un servicio en modo de usuario desea actualizar los datos de firma, debe montar el archivo de hive desde la ubicación del archivo \Windows\System32\config\ELAM. Por ejemplo, podría generar un UUID, convertirlo en una cadena y usarlo como una clave única en la que montar el hive. El formato de almacenamiento y recuperación de estos datos BLOB queda a discreción del ISV, pero los datos de firma deben ser firmados para que el controlador AM pueda comprobar la integridad de los datos.

Comprobación de firmas de malware

El método para verificar la integridad de los datos de firma de malware es responsabilidad de cada proveedor de software independiente de AM. Las funciones primitivas criptográficas de CNG están disponibles para ayudar a comprobar las firmas digitales y los certificados en los datos de firma de malware.

Error de firma de malware

Si el controlador ELAM comprueba la integridad de los datos de la firma y se produce un error en esa comprobación, o si no hay datos de firma, la inicialización del controlador ELAM sigue funcionando correctamente. En este caso, para cada controlador de arranque, el controlador ELAM debe devolver "unknown" para cada devolución de llamada de inicialización. Además, el controlador ELAM debe pasar esta información al componente de AM en tiempo de ejecución una vez iniciado.

Descarga del controlador AM

Cuando la devolución de llamada StatusType es BdCbStatusPrepareForUnload, se trata de una indicación al controlador AM de que se han inicializado todos los controladores de arranque y que el Controlador AM debe prepararse para ser descargado. Antes de descargar, el controlador AM de arranque temprano debe anular el registro de sus devoluciones de llamada. No se puede realizar la cancelación de registro durante un callback; en su lugar, tiene que ocurrir en la función DriverUnload, que el controlador puede especificar durante DriverEntry.

Para mantener la continuidad en la protección contra malware y asegurar una correcta transferencia, el motor AM en tiempo de ejecución debe iniciarse antes de que se descargue el controlador AM de inicio temprano. Esto significa que el motor AM de tiempo de ejecución debe ser un controlador de arranque comprobado por el controlador AM de inicio temprano.

Rendimiento

El controlador debe cumplir los requisitos de rendimiento definidos en la tabla siguiente:

Inicialización de controladores

Una vez que el controlador ELAM evalúa los controladores de arranque, el kernel usa la clasificación devuelta por ELAM para decidir si inicializar el controlador. Esta decisión viene determinada por la directiva y se almacena aquí en el Registro en:

HKLM\System\CurrentControlSet\Control\EarlyLaunch\DriverLoadPolicy

Esto se puede configurar a través de la directiva de grupo en un cliente unido a un dominio. Una solución antimalware puede querer exponer esta funcionalidad al usuario final en escenarios no administrados. Los siguientes valores se definen para DriverLoadPolicy:

PNP_INITIALIZE_DRIVERS_DEFAULT 0x0  (initializes known Good drivers only)
PNP_INITIALIZE_UNKNOWN_DRIVERS 0x1  
PNP_INITIALIZE_BAD_CRITICAL_DRIVERS 0x3 (this is the default setting)
PNP_INITIALIZE_BAD_DRIVERS 0x7

Errores de arranque

Si se omite un controlador de arranque debido a la directiva de inicialización, el kernel continúa intentando inicializar el siguiente controlador de arranque en la lista. Esto continúa hasta que se inicializan todos los controladores o se produjo un error de arranque porque un controlador de arranque omitido era fundamental para el arranque. Si el bloqueo se produce después de iniciar la pila de discos, hay un volcado de bloqueo que contiene información sobre el motivo del bloqueo, lo cual incluye información sobre los controladores que faltan. Esto se puede usar en WinRE para determinar la causa del error e intentar corregirlo.

ELAM y arranque medido

Si el controlador ELAM detecta una infracción de directiva (un rootkit, por ejemplo), debe llamar inmediatamente a Tbsi_Revoke_Attestation para invalidar los PCR que indicaron que el sistema estaba en un buen estado. La función devuelve un error si hay un problema con el arranque medido, por ejemplo, sin TPM en el sistema.

Tbsi_Revoke_Attestation se puede llamar desde el modo kernel. Extiende PCR[12] por un valor no especificado e incrementa el contador de eventos en el TPM. Ambas acciones son necesarias, por lo que la confianza se rompe en todas las citas que se crean desde aquí en adelante. Como resultado, los registros de arranque medidos no reflejarán el estado actual del TPM durante el resto del tiempo que el TPM está encendido y los sistemas remotos no podrán confiar en el estado de seguridad del sistema.