Ring -2: el modo que ni el hipervisor puede verRing -2: the mode not even the hypervisor can see

El firmware manda primero#

Cuando montas un laboratorio para desarrollar drivers, lo primero que aprendes no tiene nada que ver con el kernel. Tiene que ver con la BIOS. En mi guía de laboratorio lo dejé escrito así: la virtualización se activa en la BIOS/UEFI, no en el SO ni en el hipervisor. Y hay una segunda lección del mismo estilo: con Secure Boot activo, Windows no te deja ni activar el modo de pruebas para drivers. El cambio se rechaza con un mensaje que no admite discusión: protected by Secure Boot policy.

Las dos reglas dicen lo mismo. Las condiciones del juego las fija algo que se ejecuta antes que Windows. Lo que casi nadie cuenta es que ese algo no desaparece cuando arranca el sistema operativo: una parte del firmware sigue ahí, en un modo de la CPU que ni el kernel ni el hipervisor pueden ver.

En esta serie hemos ido bajando escalones. En la primera parte cruzamos de Ring 3 a Ring 0, el kernel. En la segunda encontramos al hipervisor, Ring -1, vigilando al kernel desde abajo. Siempre con la misma pregunta de fondo: cada nivel vigila al de arriba, pero ¿quién vigila al de abajo? Hoy llegamos al último escalón de la CPU: Ring -2, el System Management Mode.

Qué es SMM#

El System Management Mode (SMM) es un modo especial de las CPU x86, reservado al firmware. Existe desde el Intel 386SL, de 1990, y sigue presente en cualquier procesador Intel o AMD actual. Como el VMX root de la entrada anterior, no es un anillo nuevo en sentido estricto: es un modo de funcionamiento distinto. Pero está por debajo de todo lo que hemos visto hasta ahora.

A SMM no se entra con una instrucción normal ni con una syscall. Se entra con una interrupción especial, la SMI (System Management Interrupt). Puede generarla el chipset o el propio hardware (por eventos de energía, de temperatura o de la plataforma) o el software: en muchas plataformas Intel basta con escribir en el puerto de E/S 0xB2.

Cuando llega una SMI, la CPU hace algo que no hace en ningún otro caso:

1. Guarda todo su estado —registros, modo en el que estaba, por dónde iba— en una zona de memoria especial, la SMRAM.
2. Pasa a SMM y ejecuta el manejador de SMI del firmware, que también vive en la SMRAM.
3. Al terminar, el manejador ejecuta la instrucción RSM (Resume from System Management Mode): la CPU restaura el estado guardado y el sistema continúa exactamente donde estaba, sin saber que se detuvo.

La clave de la seguridad de SMM es la SMRAM. Solo es accesible estando en SMM: el chipset y unos registros de la CPU llamados SMRR (System Management Range Registers) la protegen, y el firmware la bloquea antes de ceder el control al sistema operativo. En la configuración habitual, ni el kernel ni el hipervisor pueden leerla, ni pueden interceptar la SMI. El hipervisor, que en la entrada anterior lo veía todo, aquí no ve nada.

Para qué se usa#

Suena inquietante, pero SMM existe por razones muy prosaicas. Es el sitio donde el firmware hace trabajo de plataforma que no puede delegar en el sistema operativo, porque no sabe qué sistema operativo habrá ni si se portará bien:

• Energía y temperatura. Parte de la gestión de energía y de la respuesta a eventos térmicos pasa por manejadores de SMI.
• Emulación de hardware heredado. El ejemplo clásico: un teclado USB que, durante el arranque, se presenta como un teclado PS/2 para que el software antiguo lo entienda.
• Servicios del firmware. Proteger la escritura de la flash donde vive la BIOS, o guardar las variables UEFI autenticadas (entre ellas, las bases de datos de claves de las que depende Secure Boot) sin que el sistema operativo pueda alterarlas por su cuenta.

Este último punto cierra el círculo del principio. Las reglas que pone el firmware antes de arrancar Windows se sostienen, en parte, gracias a código que sigue ejecutándose en SMM mientras Windows está en marcha.

El coste invisible#

Hay un precio. Mientras dura una SMI, normalmente todos los núcleos de la CPU entran en SMM, no solo el que la recibió. El sistema operativo no se entera: sus relojes siguen corriendo, pero durante ese tiempo no se ha ejecutado ni una instrucción suya. Simplemente, lo pierde.

Para un escritorio da igual. Para un sistema de tiempo real, donde una tarea tiene que responder en un plazo garantizado, es un problema serio: aparecen pausas que nadie en el sistema ha causado y que ninguna herramienta del sistema puede atribuir a un proceso. Linux incluye un trazador pensado precisamente para eso, hwlat, que ocupa un núcleo dando vueltas y mide los huecos de tiempo que no puede explicar. Es una de las pocas formas de notar SMM desde fuera: no por lo que hace, sino por el tiempo que se lleva.

Por qué es un objetivo tan delicado#

Todo lo que hemos visto en la serie apunta a la misma conclusión. Un fallo en Ring 0 compromete al kernel; el hipervisor está ahí para contenerlo. Un fallo en Ring -1 compromete a todas las máquinas virtuales que están encima. Un fallo en código SMM da control por debajo incluso del hipervisor, en un sitio que ninguna de las defensas de arriba puede ver.

La clase de fallo más conocida en SMM tiene nombre de manual: la del ayudante confundido (confused deputy). El manejador de SMI tiene todos los privilegios, pero a menudo trabaja con datos que le pasa el sistema operativo: un búfer con una petición, un puntero a dónde dejar la respuesta. Si el manejador no valida esos búferes y punteros, el sistema operativo —o un atacante que lo controle— puede engañarlo para que lea o escriba donde no debe, por ejemplo dentro de la propia SMRAM. El ayudante tiene las llaves; el problema es que obedece sin comprobar a quién.

No hace falta entrar en cómo se aprovecha eso. Lo que importa aquí es la respuesta: las mitigaciones que la industria ha ido exigiendo al código SMM atacan justo ese punto.

WSMT: el firmware declara sus defensas#

Microsoft definió una tabla ACPI con un nombre muy descriptivo: la Windows SMM Security Mitigations Table (WSMT). Con ella, el firmware declara que su código SMM aplica tres protecciones:

Las dos primeras son la respuesta directa al ayudante confundido: el manejador solo acepta peticiones en sitios conocidos y comprueba cada puntero antes de seguirlo. La tercera evita que el sistema operativo cambie la configuración del hardware de la que depende la protección de SMM.

Windows consulta esta tabla para decidir si confía en el firmware para las funciones de seguridad basada en virtualización (VBS) que vimos en Ring -1. Tiene todo el sentido: de poco sirve que el hipervisor proteja al kernel si por debajo del hipervisor hay código que se lo puede saltar. Los equipos Secured-core van más allá y añaden mecanismos de Intel y AMD que aíslan o supervisan el propio código SMM, para no depender solo de que esté bien escrito.

Compruébalo tú mismo#

Windows expone las tablas del firmware a cualquier programa, sin privilegios de administrador, con dos funciones: EnumSystemFirmwareTables lista las que hay y GetSystemFirmwareTable devuelve el contenido de una. Este programa lista las tablas ACPI de tu equipo y lee la WSMT. A diferencia de las partes anteriores, es código solo para Windows:

// g++ -std=c++20 firmware.cpp -o firmware.exe   (Windows)
// Lista las tablas ACPI del firmware y lee la WSMT, donde el
// firmware declara qué protecciones aplica a su código SMM.
#include <windows.h>
#include <cstdint>
#include <cstring>
#include <format>
#include <iostream>
#include <string>
#include <vector>

// El proveedor se codifica con el primer carácter en el byte alto...
constexpr DWORD provider(const char s[5]) {
    return DWORD(s[0]) << 24 | DWORD(s[1]) << 16
         | DWORD(s[2]) << 8 | DWORD(s[3]);
}
// ...y la firma de una tabla, con sus bytes en el orden de memoria.
DWORD table(const char s[5]) {
    DWORD v;
    std::memcpy(&v, s, 4);
    return v;
}

int main() {
    const DWORD acpi = provider("ACPI");

    // 1. Qué tablas hay: cada entrada son 4 bytes con su firma.
    std::vector<char> ids(EnumSystemFirmwareTables(acpi, nullptr, 0));
    EnumSystemFirmwareTables(acpi, ids.data(), DWORD(ids.size()));
    std::cout << "ACPI tables:";
    for (size_t i = 0; i + 4 <= ids.size(); i += 4)
        std::cout << (i % 36 ? " " : "\n  ") << std::string(&ids[i], 4);
    std::cout << '\n';

    // 2. WSMT: cabecera ACPI (36 bytes) + ProtectionFlags (4 bytes).
    const DWORD wsmt = table("WSMT");
    DWORD size = GetSystemFirmwareTable(acpi, wsmt, nullptr, 0);
    if (size < 40) {
        std::cout << "WSMT: not present\n";
        return 0;
    }
    std::vector<uint8_t> t(size);
    GetSystemFirmwareTable(acpi, wsmt, t.data(), size);
    uint32_t flags;
    std::memcpy(&flags, t.data() + 36, 4);

    const char* names[] = {"FIXED_COMM_BUFFERS",
                           "COMM_BUFFER_NESTED_PTR_PROTECTION",
                           "SYSTEM_RESOURCE_PROTECTION"};
    std::cout << std::format("WSMT ProtectionFlags = 0x{:X}\n", flags);
    for (int bit = 0; bit < 3; ++bit)
        std::cout << std::format("  {:<34}{}\n", names[bit],
                                 (flags >> bit) & 1 ? "yes" : "no");
}

Esta es la salida real en mi equipo, un Intel Core i9-14900KF con Windows 11:

ACPI tables:
  DBGP MCFG FACP APIC DMAR HPET FPDT FIDT SSDT
  SSDT SSDT SSDT SSDT UEFI NHLT LPIT SSDT SSDT
  DBG2 SSDT SSDT SSDT SSDT PHAT TPM2 WSMT BGRT
WSMT ProtectionFlags = 0x7
  FIXED_COMM_BUFFERS                yes
  COMM_BUFFER_NESTED_PTR_PROTECTION yes
  SYSTEM_RESOURCE_PROTECTION        yes

ProtectionFlags = 0x7 son los tres bits a uno: el firmware declara las tres protecciones. Pero la lista de tablas merece una segunda mirada, porque en ella aparecen otras dos piezas de la cadena de seguridad:

• DMAR es la tabla que describe la IOMMU de Intel (VT-d). La IOMMU hace con los dispositivos lo que las tablas EPT hacen con las máquinas virtuales: decide a qué memoria puede acceder cada uno por DMA. Es el hardware en el que se apoya Windows para la protección de DMA del kernel, la que impide que un dispositivo conectado lea o escriba la memoria del sistema a su antojo.
• TPM2 describe el chip TPM, la raíz de las mediciones del arranque: cada etapa del arranque se mide y se registra en él antes de ejecutarse.

Cómo se codifican las firmas#

El detalle más curioso del código son las dos funciones del principio, que convierten cuatro letras en un DWORD de dos formas distintas. No es un capricho: la API las espera así.

El proveedor ('ACPI') se codifica con el primer carácter en el byte alto, como se escribiría un literal de varios caracteres: 0x41435049, con la A (0x41) delante. La firma de una tabla, en cambio, se pasa con sus bytes en el mismo orden en que aparecen en memoria, que es como está guardada en la propia tabla ACPI. En un x86, que es little-endian, "WSMT" se convierte así en 0x544D5357: la W (0x57) acaba en el byte bajo. Por eso table() usa memcpy, que copia los bytes tal cual, en lugar de desplazamientos. Si te equivocas de orden, no salta ningún error llamativo: GetSystemFirmwareTable busca una tabla que no existe, devuelve 0 y el programa dirá que no hay WSMT aunque la haya.

El resto sigue la anatomía de la WSMT: una cabecera ACPI estándar de 36 bytes, común a todas las tablas, seguida de un único campo de 4 bytes, ProtectionFlags. Por eso el programa exige al menos 40 bytes antes de leer nada y toma los flags del desplazamiento 36. (El 36 del bucle de la lista es otra cosa: 9 firmas de 4 bytes por línea.)

Ring -3, en una frase#

Por debajo de SMM ya no queda CPU. Pero fuera de la CPU principal viven microcontroladores con su propio firmware —Intel ME / CSME en Intel, AMD PSP en AMD— que gestionan el arranque seguro, el TPM por firmware y la administración remota, y que pueden seguir funcionando mientras la CPU principal está en reposo. Hay quien los llama Ring -3. Son otro ordenador dentro de tu ordenador, y con eso cerramos la escalera.

La escalera completa#

Tres entradas después, esta es la escalera que hemos bajado:

La columna de la derecha cuenta la historia de la serie. Cada nivel protege al de arriba, y cada vez es más difícil encontrar a alguien por debajo que proteja al protector. Por eso la seguridad de un sistema moderno no es una muralla, sino una cadena: aplicación, kernel, hipervisor, firmware. Y el eslabón más bajo de esa cadena, el que sostiene a todos los demás, es el firmware.

Si has empezado por esta entrada, la serie empieza en De Ring 3 a Ring 0 y sigue en Ring -1: el hipervisor que vigila a tu kernel.

La próxima vez que entres en la BIOS para activar la virtualización, recuerda con quién estás hablando: con el único nivel que seguirá ahí, sin que nadie lo vea, cuando el sistema operativo crea que manda él.