Guía para arrancar por HTTP(S) con UEFI, Qemu y OVMF

Fuentes: Introduction to UEFI HTTP(S) boot with Qemu/OVMF

El arranque por red tradicional (PXE) se basa en DHCP y TFTP, protocolos difíciles de configurar, poco seguros y sin soporte de alta disponibilidad. La web moderna estandarizó HTTPS con certificados TLS, que ofrecen autenticación, integridad y confidencialidad. La mayoría de los sistemas UEFI actuales soportan arranque por HTTP(S), lo que permite aprovechar estas ventajas. Este artículo explica cómo configurar un arranque por HTTP(S) con Qemu y OVMF, paso a paso, destacando los problemas y soluciones encontrados.

En primer lugar, se presenta un caso simple: arranque HTTP descubierto vía DHCP, usando la variante snponly de netboot.xyz. La configuración inicial falla porque OVMF requiere un generador de números aleatorios (RNG) para su pila de red. Añadir el dispositivo virtio-rng-pci soluciona el problema. Este requisito está declarado en la sección Depex de DxeNetLib.inf, lo que demuestra la dependencia de forma implícita.

Una vez funcional, el arranque tarda aproximadamente 1 minuto y 15 segundos, debido a que OVMF intenta secuencialmente PXE IPv4, PXE IPv6, HTTP IPv4 y HTTP IPv6. Para acelerarlo, se deshabilitan los soportes PXE heredados mediante parámetros -fw_cfg de Qemu (opt/org.tianocore/IPv4PXESupport y opt/org.tianocore/IPv6PXESupport a 'no'). Con ello, el arranque se logra en unos 5 segundos.

Como alternativa a los parámetros de firmware, se pueden utilizar variables UEFI para lograr una configuración portable a hardware real. El artículo anticipa que esta vía allana el camino para HTTPS, cuyo desafío principal es la verificación de certificados TLS en el entorno UEFI. Se menciona que versiones antiguas de Qemu y OVMF podrían funcionar mejor para HTTPS, aunque la configuración avanzada queda para una segunda parte.

Consideraciones prácticas: se emplea Qemu con red SLIRP en modo usuario, sin almacenamiento, todo en memoria. La solución es útil para entornos virtualizados, laboratorios o pruebas rápidas, pero en producción habrá que gestionar certificados, alta disponibilidad y compatibilidad con hardware real. El uso de iPXE como firmware intermedio facilita la integración con repositorios remotos.