Un molino llamado SMI: leer un BSOD con una IA local cuando el culpable no está donde Windows dice (CASO II)

PC confidencial que «falla aleatoriamente»

Workstation Intel reciente con SGX habilitado, Windows 11, perfil de uso mixto: durante la jornada cargan enclaves para servicios de atestación remota, un runtime confidencial basado en el Intel SGX SDK, y un cliente de juegos que en sus ratos libres invoca un anticheat también basado en enclaves. Por encima de todo eso, la imagen corporativa ha instalado un agente de seguridad EDR con un módulo comercial. El usuario reporta:

• BSOD intermitentes, dos o tres por semana, sin coincidir nunca con la misma aplicación en foco.
• Bug check siempre el mismo: 0x133 (DPC_WATCHDOG_VIOLATION).
• Una correlación que sólo aparece después de mirar mucho: los crashes son más probables durante sesiones largas con enclaves activos. No es determinista; es una distribución sesgada.

El primer reflejo es revisar drivers gráficos (y en mi experiencia cabe destacar un crash importante en un servidor de BB.DD. al actualizar los drivers gráficos, allá por el año 2000, asi que no es extraño sospechar), de red y de almacenamiento. El segundo (también malo) es pasar el verifier.exe en modo paranoico, lo que dispara más BSODs sin acercar la respuesta. El tercero (el útil) es preguntarse qué dice exactamente WER.

Abrimos CrashDetectorwithAI tras el siguiente crash. La aplicación presenta de forma estructurada algo equivalente a esto:

Y, debajo, la respuesta del modelo local (Phi-4 vía ONNX) en streaming, que viene a decir, con palabras propias y prudentes, algo como:

Se trata de un DPC_WATCHDOG_VIOLATION. El parámetro 1 con valor 0 indica que se ha superado el umbral acumulado de DPC en un solo procesador. Los valores 0x501 y 0x500 son los ticks observado y permitido, expresados en unidades del kernel. La dirección final apunta a nt!KeAccumulateTicks, lo cual es habitual: el watchdog se dispara desde la contabilidad de tiempo del kernel, no desde la DPC culpable. Causas frecuentes: driver con DPC excesivamente larga, problema de firmware/BIOS que bloquea la CPU, o controlador de almacenamiento (storport/NVMe) bajo presión. Recomendaciones iniciales: actualizar BIOS, drivers de chipset y de almacenamiento; revisar utilidades de fabricante que interactúen con el firmware; ejecutar LatencyMon en estado normal de uso.

El culpable: una suite de seguridad SGX-aware que abusa de SMM

En el caso real que motiva este artículo, el responsable resultó ser un patrón más sutil que el clásico abuso de SMI por una utilidad de fabricante. La cadena fue ésta:

1. El driver kernel-mode del agente EDR ejecuta cada 5–8 segundos una secuencia que termina escribiendo en una MSR registrada por el firmware como gatillo de software SMI. La razón nominal es muestrear el estado de los enclaves cargados: número, identidad, signature hash, y la última información de la atestación.
2. El handler SMI correspondiente, alojado en SMRAM, hace dos cosas distintas. Primero, lee un puñado de MSRs relacionados con SGX (IA32_SGXLEPUBKEYHASH0..3, IA32_FEATURE_CONTROL, revisión de microcódigo, indicadores de SGX2). Esa parte es barata: decenas de microsegundos. Segundo, y aquí es donde el handler pierde la inocencia, consulta a Intel Management Engine vía la interfaz HECI/MEI para validar el estado de las claves de atestación. Esa consulta puede gastar entre 5 y 15 ms según lo que ME esté haciendo en su propio dominio, que el SO ni ve ni controla.
3. A la vez, cada SMI invocado mientras hay enclaves activos provoca un Asynchronous Enclave Exit en cada núcleo donde un enclave estuviera en ejecución. Recordemos lo establecido en la entrada del 15 de mayo: SMM no puede leer el EPC, pero la transición no es gratuita. Cada AEX implica salvar el estado del enclave en la SSA, sustituir los registros visibles por valores sintéticos, y, al volver, un ERESUME que cuesta del orden de 50–200 µs por núcleo afectado.
4. Multiplicado por la cadencia observada de 8–15 SMIs por segundo (los 116 / 10s que vimos en MSR 0x34), y por dos o tres enclaves activos durante la jornada, el sistema acumula ventanas SMM que en el peor caso, cuando ME está contendido por sus propias tareas de fondo, superan el umbral del DPC watchdog y disparan el 0x133.

Lo elegante de este patrón es doble. Por un lado, WER no puede ver nada de lo anterior: el handler vive en firmware, la consulta a ME ocurre fuera del espacio observable por el kernel, y el AEX se resuelve antes de que el SO siquiera registre que la SMI ha existido. El bucket dice nt!KeAccumulateTicks y se queda tan tranquilo. Por otro lado, el coste indirecto sobre el rendimiento de los enclaves SGX (la degradación silenciosa que no llega a BSOD pero ralentiza cualquier carga confidencial seria) es invisible para el equipo de seguridad que opera la suite: ellos miden el coste de su agente en espacio de usuario, donde la huella es un servicio que consume 20 MB de RAM y 0,3% de CPU. La factura real, pagada en latencia SMM y en throughput de enclave, queda fuera de su panel.

La resolución, una vez identificado el patrón, es proporcional:

• Desactivar el módulo SGX Visibility del EDR en la consola del agente. El resto del EDR (detección de comportamiento, prevención de ejecución, telemetría kernel-mode) puede mantenerse intacto. La «visibilidad sobre enclaves» que se pierde con esto es, en la práctica, decorativa: el agente no podría inspeccionar el EPC ni aunque tuviese privilegio para hacerlo.
• Si el equipo de seguridad necesita esa visibilidad por requisitos de compliance, migrar a herramientas basadas en DCAP (Data Center Attestation Primitives, parte del SGX SDK de Intel). DCAP expone el estado de los enclaves desde kernel-mode sin atravesar firmware: el coste, para el plano de la plataforma, es despreciable.
• Para casos OEM con handlers HECI generosos, actualización de firmware a una versión donde la consulta a ME se difiera, se cachee o se agrupe.
• Verificación posterior: el MSR 0x34 cae por debajo de 1 SMI/s en idle, LatencyMon vuelve a verde, el contador de AEX expuesto por el SGX SDK deja de mostrar correlación con la actividad del agente, y los 0x133 desaparecen del Visor de Eventos.

Referencias

• Entrada relacionada en este blog: Forense de memoria en SGX ante sospecha de intromisión vía SMI (15 mayo 2026).
• Entrada relacionada en este blog: Un molino llamado SMI: leer un BSOD con una IA local cuando el culpable no está donde Windows dice (CASO I) (18 mayo 2026).