Requisitos previos de las pruebas antimalware de inicio anticipado
En esta sección se describen las tareas que debe completar antes de probar el controlador antimalware de inicio temprano (ELAM) mediante el Kit de laboratorio de hardware de Windows (Windows HLK):
La característica de software ELAM proporciona un mecanismo compatible con Microsoft para que el software antimalware se inicie antes de todos los demás componentes de terceros. El sistema inicializa primero los controladores antimalware y permite a estos controladores controlar la inicialización de controladores de arranque, de modo que el sistema no inicialice controladores de arranque desconocidos. Una vez que el proceso de arranque haya inicializado los controladores de arranque y el acceso al almacenamiento persistente esté disponible de forma eficaz, el software antimalware existente puede seguir bloqueando la ejecución de malware.
Para obtener más información, consulte Entorno de firmware y arranque.
Requisitos de hardware
Se requiere el siguiente hardware para las pruebas:
- Dos equipos de prueba. Estos equipos de prueba deben cumplir los requisitos previos de Windows HLK y deben incluirse en el mismo grupo de equipos. Para obtener más información, consulte Requisitos previos de Windows HLK.
Nota
Para certificar el producto para su uso en servidores, el equipo de prueba debe admitir cuatro procesadores y un mínimo de 1 GB de RAM. Estas funcionalidades del sistema son necesarias para probar la funcionalidad Rebalance, D3 State y Multiple Processor Group del dispositivo y el controlador. No necesita un equipo que tenga más de 64 procesadores para probar el dispositivo. Además, los sistemas de servidor que se usan para las pruebas de dispositivos o controladores deben tener Server Core instalado antes de las pruebas. Para obtener más información, vea Opciones de instalación de Windows Server.
Si usa un grupo de equipos de prueba para probar el producto, al menos un equipo del grupo debe contener cuatro procesadores y un mínimo de 1 GB de RAM. Además, ese equipo debe contener el producto que desea probar. Siempre que el controlador sea el mismo en todos los equipos del grupo, el sistema crea una programación para ejecutarse en todos los equipos de prueba.
En el caso de las pruebas que no incluyen un controlador para probar, como las pruebas de unidades de disco duro, el programador HLK de Windows restringe las pruebas que validan el reequilibrio del controlador y el reequilibrio del controlador, el estado D3 y la funcionalidad de varios grupos de procesadores para ejecutarse en el equipo de prueba predeterminado. Debe configurar manualmente este equipo para que tenga varios grupos de procesadores. El equipo predeterminado es el primer equipo de prueba de la lista. El personal de pruebas debe asegurarse de que el primer equipo de prueba de la lista cumple los requisitos mínimos de hardware.
Nota
Excepto para los controladores de para-virtualization (tal y como se define en el documento de directivas y procesos de WHCP ), no puede usar ninguna forma de virtualización al probar dispositivos físicos y sus controladores asociados para la certificación o firma del servidor. Todos los productos de virtualización no admiten la funcionalidad subyacente necesaria para pasar las pruebas relacionadas con varios grupos de procesadores, la administración de energía de dispositivos, la funcionalidad PCI del dispositivo y otras pruebas.
Nota
Configuración de varios grupos de procesadores Debe establecer el valor para el tamaño del grupo de procesadores para las pruebas del Kit de laboratorio de hardware de Windows Server 2008 R2 y versiones posteriores para la certificación. Para ello, ejecute bcdedit en una ventana del símbolo del sistema con privilegios elevados mediante la opción /set.
Los comandos para agregar la configuración del grupo y reiniciar son los siguientes:
bcdedit.exe /set groupsize 2
bcdedit.exe /set groupaware on
shutdown.exe -r -t 0 -f
Los comandos para quitar la configuración del grupo y reiniciar son los siguientes:
bcdedit.exe /deletevalue groupsize
bcdedit.exe /deletevalue groupaware
shutdown.exe -r -t 0 -f
Nota
Configuración de integridad de código
La característica Seguridad basada en virtualización (VBS) de Windows Server 2016 debe habilitarse primero mediante Administrador del servidor.
Una vez que se haya producido, se debe crear y establecer la siguiente clave del Registro:
HKLM\System\CurrentControlSet\Control\DeviceGuard
HypervisorEnforcedCodeIntegrity:REG_DWORD
0 or 1 (disabled, enabled)
Requisitos de software
Se requiere el siguiente software para las pruebas:
El controlador que está probando.
Advertencia
Asegúrese de instalar el producto en el equipo de prueba antes de instalar el cliente HLK de Windows.
Las actualizaciones o filtros HLK de Windows más recientes.
Prueba de la configuración del equipo
Si va a probar controladores de modo kernel sin firmar, elija una de las siguientes opciones:
Adjunte un depurador de kernel. En este caso, el sistema no comprueba ni aplica firmas de controlador. Por lo tanto, cualquier controlador puede cargarse incluso si el controlador no tiene un certificado comprobado o el controlador no está firmado.
Cree un certificado autofirmado mediante el archivo makecert.exe. El certificado debe contener las EKU 1.3.6.1.5.5.7.3.3 (codesigning) y 1.3.6.1.4.1.311.61.4.1 (inicio temprano). Después, deshabilite el arranque seguro (si está habilitado) o habilite la depuración de arranque seguro y coloque el equipo en modo de prueba mediante el comando bcdedit /set testsigning on . El modo de prueba significa que el sistema valida la firma y comprueba las EKU, pero el sistema no comprueba la cadena de certificados.
Asegúrese de que el equipo de prueba está en estado listo antes de comenzar las pruebas. Si una prueba requiere que se establezcan parámetros antes de que se ejecute, se mostrará un cuadro de diálogo para esa prueba. Revise el tema de prueba específico para obtener más información.
Algunas pruebas de Windows HLK requieren intervención del usuario. Al ejecutar pruebas para un envío, se recomienda ejecutar las pruebas automatizadas en un bloque por separado de las pruebas manuales. Esto impide que una prueba manual interrumpa la finalización de una prueba automatizada.