openSUSE:UEFI

Contenido

1 UEFI
2 Secure Boot
3 Ver también

UEFI

Introducción al estándar

UEFI (Unified Extensible Firmware Interface) es un nuevo estándar de la industria que especifica las distintas interfaces que debe proporcionar un sistema en un entorno previo al arranque. UEFI controla el sistema después de su encendido y de que se haya cargado por completo el sistema operativo. También es responsable de proporcionar una interfaz entre los recursos que provee el sistema y el sistema operativo.

En otras palabras, UEFI llega para sustituir y extender el antiguo firmware de la BIOS.

UEFI no es algo nuevo. Intel ha estado trabajando en EFI/UEFI desde mediados de 1990, y hay fabricantes como HP o Apple que proporcionan máquinas EFI desde hace mucho. Pero no ha sido hasta que Microsoft anunciara Windows 8 que UEFI se convirtiera en un requisito obligatorio para poder arrancar las nuevas máquinas certificadas.

La especificación de UEFI (http://www.uefi.org/specs/) es un extenso documento que contiene todas las interfaces, variables y estructuras que deben proporcionar los productores de firmware, y que son accesibles para el sistema operativo. La buena noticia es que Linux ha sido capaz de utilizar EFI durante el arranque desde el año 2000 usando GRUB o elilo. De hecho, openSUSE 12.2 tenía soporte para UEFI, y el reciente openSUSE 12.3 tiene soporte experimental para la extensión Secure Boot (arranque seguro).

Secure Boot es una extensión de UEFI. Uno de los puntos clave de UEFI es que se puede extender. UEFI tiene una máquina virtual interna que es independiente de la arquitectura en la que se esté usando. El estándar acepta ficheros binarios especiales compilados para esta máquina virtual (binarios EFI) que se pueden ejecutar dentro del entorno. Esos archivos binarios pueden ser controladores de dispositivos, aplicaciones o extensiones al estándar UEFI. UEFI, en cierto sentido, es como un pequeño sistema operativo que se ejecuta al encender la máquina y cuya tarea principal es encontrar y cargar otro sistema operativo.

¿Cómo se sabe si se tiene una máquina UEFI? Normalmente se puede comprobar la configuración firmware pulsando F1 (o ESC u otra tecla, depende de la máquina) durante el proceso de encendido. Navegando por los menús se puede encontrar que la máquina puede funcionar en modo antiguo (el viejo modo BIOS, legacy en inglés), en modo EFI y en modo híbrido, y dicho modo se selecciona en base al sistema operativo que estemos cargando.

Si la máquina no tiene soporte para UEFI y quieres probar ésta nueva tecnología con openSUSE, puedes usar QEMU y la implementación de referencia de UEFI creada por Intel: UEFI y Secure Boot con QEMU (en inglés).

GPT

UEFI cambia más cosas aparte del firmware, las llamadas al sistema y las interfaces. También propone un nuevo estilo de particionado de discos duros. GUID Partitioning Table (tabla de particiones GUID o GPT para abreviar) llega para sustituir al viejo Master Boot Record (registro maestro de arranque o MBR).

MBR tiene algunas limitaciones importantes como el número de particiones primarias y lógicas y el tamaño de dichas particiones. GPT soluciona estos problemas y ahora se puede tener un número arbitrario de particiones (en conjuntos de 128) y un espacio de disco direccionable de 2^64 bytes (es decir, está en el orden de los exabytes). Así, si se tienen discos de gran tamaño, este es el tipo de particionado más adecuado. Otra diferencia fundamental es que GPT hace referencia a cada partición usando un número UUID (Universally Unique Identifier o, en español, Identificador universalmente único), lo que evita la coincidencia entre los identificadores de las particiones.

Si YaST detecta que se está en modo EFI tratará de crear una partición GPT por sí mismo durante una instalación limpia (es decir, cuando no se trata de una actualización de una versión anterior). Una vez que las particiones GPT están en su sitio, no se puede usar más el antiguo fdisk para crear, eliminar o editar particiones. La nueva herramienta para hacer ésto es gdisk, que pertenece al paquete gptfdisk. La interfaz es la misma de fdisk.

fdisk y gdisk con una partición GPT

De vez en cuando, si se piensa en hacer algunas pruebas y experimentos con los distintos modos, se querrá eliminar el formato GPT del disco duro. Se puede hacer usando YaST2. Hay que seleccionar la opción Particionado personalizado (para expertos), elegir el disco duro correcto y en el botón Configurar... se escoge Crear una nueva tabla de particiones.

Crear una tabla de particiones nueva destruye todas las particiones que existan y los datos que contengan. ¡Deberías hacer una copia de seguridad de tus datos primero, antes de realizar este proceso!

Modo de particionado para expertos

Esto sustituye la tabla de particiones de acuerdo al sistema que estamos ejecutando.

Partición del sistema EFI

La EFI System Partition (ESP, partición del sistema EFI), es una partición en la que UEFI espera encontrar los programas EFI que se pueden usar para arrancar todos los sistemas operativos instalados en el dispositivo. Ademas, EFI encuentra allí algunos controladores de dispositivo que se usan durante el arranque y otras herramientas que se deben ejecutar antes de que el sistema operativo haya arrancado.

Esta partición usa el sistema de archivos FAT y puede crease con YaST durante una instalación nueva o se puede reutilizar en una máquina con arranque doble. Esto significa que si se tiene una instalación previa de Windows en el sistema, YaST2 detectará la partición EFI, pondrá el nuevo cargador de arranque EFI que se usa para cargar openSUSE y montará la partición en el punto de montaje /boot/efi.

Punto de montaje para la partición EFI

Por defecto, el firmware usa /EFI/BOOT/bootx64.efi como una extensión que carga y ejecuta para arrancar el sistema operativo. En máquinas Windows la extensión correcta está en /EFI/Microsoft/Boot/BCD.efi, y en openSUSE está en /EFI/opensuse/grubx64.efi (o shim.efi si se tiene la opción Secure Boot habilitada).

Contenido de la partición EFI

El cargador de arranque

Para poder seleccionar la extensión correcta para cargar el sistema operativo, EFI proporciona al usuario un cargador de arranque interno. El sistema operativo es el responsable de crear una nueva entrada para sí mismo. Se puede iniciar el cargador de arranque y listar todas las opciones de arranque durante el proceso de encendido, pulsando F9 o F12 normalmente. Pero también se puede usar la herramienta efibootmgr para consultar y editar las opciones. Por ejemplo, para listar las opciones que hay actualmente se puede ejecutar efibootmgr -v.

Opciones en el cargador de arranque

En la imagen anterior se puede ver que openSUSE creó dos opciones distintas para arrancar. Una se usa en el modo seguro y la otra cuando no lo es.

Si por algún motivo se pierde alguna de las opciones, se puede reconstruir utilizando efibootmgr. Por ejemplo, para crear la opción opensuse se puede hacer así:

# efibootmgr -c -L "openSUSE-alt" -l '\EFI\opensuse\grubx64.efi'

Variables EFI

El estándar UEFI especifica un conjunto de variables que se pueden almacenar en una parte no volátil del firmware. Estas variables se utilizan para almacenar información y para controlar el comportamiento del sistema UEFI. Cuando se crea una nueva opción en el cargador de arranque, o cuando se habilita o deshabilita la opción Secure Boot, por ejemplo, se está accediendo y cambiando el valor de una de esas variables.

Se pueden consultar y tener acceso a esas variables directamente desde openSUSE vía Sysfs. Sysfs es un sistema de archivos virtual proporcionado por el kernel para exportar información interna al espacio de usuario. Se pueden encontrar las variables en /sys/firmware/efi/vars/. Así, por ejemplo, se puede consultar la última opción del cargador de arranque con

$ hexdump -C /sys/firmware/efi/vars/Boot0007-*/data

En la orden anterior se usó Boot0007, pero esa no tiene por qué ser la última opción, depende del sistema. Para ver las que hay se puede ejecutar ls /sys/firmware/efi/vars/Boot00* y la que tenga el número más alto a continuación de Boot será la última, obviamente.

Secure Boot

Antecedentes

UEFI Secure Boot es un método que limita los archivos binarios que se pueden ejecutar para arrancar el sistema. El firmware solo ejecuta cargadores de arranque que tengan una firma criptográfica de una entidad bien conocida. En el contexto de Secure Boot se usan los certificados X.509 para identificar las entidades.

Hoy en día la mayoría de hardware PC que tiene habilitado Secure Boot por defecto se vende con Microsoft Windows 8. De ahí que el firmware solo sabe de Microsoft como entidad bien conocida para firmar los cargadores de arranque. Para poder arrancar openSUSE sin tener que reconfigurar la lista de proveedores conocidos de firmas y sin tener que desactivar Secure Boot, el cargador de arranque de openSUSE debe tener la firma de Microsoft.

Implementación en openSUSE 12.3

El cargador de arranque por defecto que usa openSUSE 12.3 en sistemas UEFI es GRUB2. En el modo Secure Boot, se usa también un cargador de arranque adicional llamado shim. En vez de llamar directamente a GRUB2, en ese modo el firmware carga primero shim. shim tiene la firma de Microsoft para que pueda ser reconocido por el firmware. shim a su vez conoce el certificado de openSUSE que se usaba para firmar GRUB2. Entonces, GRUB2 es capaz de cargar los kernel de Linux que también estén firmados con certificados de openSUSE. Después de cargar el kernel de Linux termina el ámbito de Secure Boot. El kernel de Linux no impone restricciones adicionales.

Para poder tener cargadores de arranque y kernel personalizados, shim ofrece un modo de importar firmas propias. El programa MokManager se usa para ese propósito. Cuando se instruye a shim para que cargue un archivo binario que no está firmado por una entidad bien conocida éste llama a MokManager que permite la importación de certificados en la base de datos de proveedores de firmas bien conocidos.

Cómo habilitar o deshabilitar el soporte para Secure Boot

El soporte para Secure Boot en openSUSE 12.3 se considera experimental aún. El programa de instalación YaST no puede detectar automáticamente si está habilitado Secure Boot. Durante la instalación ofrece una opción para habilitar el soporte para Secure Boot de forma manual. Para que shim se instale es necesario activar dicha opción. Para habilitar o deshabilitar el soporte en un sistema instalado se puede usar el módulo para el cargador de arranque de YaST.

Cómo determinar si un sistema tiene habilitado Secure Boot

Para determinar si una máquina tiene Secure Boot habilitado en el firmware, ejecuta el siguiente comando como root en una consola:

 od -An -t u1 /sys/firmware/efi/vars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c/data

Escribe el comando hasta llegar a SecureBoot- y pulsa la tecla Tabulador para completarlo ya que lo que le sigue puede variar. Luego añada data al final, tras la última /.

Si el comando muestra '1' como salida, Secure Boot está habilitado. Se sabe que algunas versiones de firmware son defectuosas y muestran '0' aunque esté habilitado.

Arrancar un kernel personalizado

Secure Boot no impide que se pueda usar un kernel compilado por uno mismo. Solo hay que firmarlo con un certificado propio y hacer que el firmware o MOK lo reconozca.

Crear una llave X.509 y un certificado personalizado para usarlos como firma:

openssl req -new -x509 -newkey rsa:2048 -keyout key.asc -out cert.pem -nodes -days 666 -subj "/CN=$USER/"

Empaquetar llave y certificado en forma de estructura PKCS#12

openssl pkcs12 -export -inkey key.asc -in cert.pem -name kernel_cert -out cert.p12

Generar la base de datos NSS para que la use pesign
```
certutil -d . -N
```

Importar la llave y certificado que contiene PKCS#12 en la base de datos NSS
```
pk12util -d . -i cert.p12
```

Aplica la nueva firma al kernel

pesign -n . -c kernel_cert -i arch/x86/boot/bzImage -o vmlinuz.signed -s

Lista las firmas en la imagen del kernel
```
pesign -n . -S -i vmlinuz.signed
```

En este punto ya puedes instalar el kernel en /boot como de costumbre. Como el kernel tiene ahora una firma personalizada es necesario importar en el firmware o MOK el certificado que se usa para firmarlo.

Convertir el certificado al formato DER para importarlo en el firmware UEFI o MOK
```
openssl x509 -in cert.pem -outform der -out cert.der
```

Copia el certificado al ESP para un acceso más sencillo
```
sudo cp cert.der /boot/efi/
```

Desgraciadamente, mokutil aún está roto en openSUSE 12.3, así que no hay una buena forma de iniciar MOK de forma automática. El siguiente proceso describe cómo se puede iniciar MOK de forma manual.

reinicia

en el menú de GRUB pulsa la tecla 'c'

escribe (asumiendo que ESP es gpt1 en hd0)

chainloader (hd0,gpt1)/EFI/opensuse/MokManager.efi
boot

selecciona "Enroll key from disk" (significa Inscribir clave desde el disco)

navega hasta el fichero cert.der y pulsa Entrar

sigue las instrucciones para inscribir la clave. Normalmente, esto se debería conseguir pulsando '0' (cero) seguido de 'y' para confirmarlo

El menú del firmware puede proporcionar modos alternativos de añadir una nueva clave a 'db'.

Arrancar una máquina sin las claves proporcionadas por el fabricante

Si el menú del firmware ofrece la opción de reiniciar las claves que usa para Secure Boot, puedes instalar una nueva PK, KEK y db sin las claves de Microsoft. Importa /usr/lib64/efi/shim-opensuse.der en "db" para que los kernel de openSUSE puedan arrancar en ese caso. El shim por defecto está firmado tanto por Microsoft como por openSUSE. Sin embargo, algunas versiones de firmware no admiten un firmado doble. En ese caso instala /usr/lib64/efi/shim-opensuse.efi que contiene solo la firma de openSUSE como /boot/efi/EFI/opensuse/shim.efi.

Arranque en máquinas que solo admiten una firma con llaves proporcionadas por el distribuidor

Algunos firmware no pueden usar más de una firma en las imágenes EFI, y el shim por defecto falla en estos casos. Si el menú del firmware no proporciona opciones para instalar llaves nuevas, tienes que quitar la firma de openSUSE manualmente para evitar el problema.

Instala mozilla-nss-tools y pesign
```
zypper install mozilla-nss-tools pesign
```

Crea una base de datos nss temporal

mkdir certdb
certutil -N -d certdb
(press "Enter" to ignore the password request)

Borra la firma de openSUSE

pesign -n certdb/ -r -i /usr/lib64/efi/shim.efi -o shim.efi -u 1

Sustituye el shim.efi por defecto con el recién generado shim.efi
```
mv shim.efi /boot/efi/EFI/opensuse/shim.efi
```
Elimina la base de datos nss temporal
```
rm -rf certdb
```

Se deben repetir los pasos cada vez que se actualice el shim. Estos firmware serán cada vez menos corrientes porque hace más de un año que se incluyó en origen el soporte para múltiples firmas en el ed2k, pero aún podría ser útil para máquinas más antiguas.

Glosario

PK: La "Platform Key" hace referencia normalmente a un certificado instalado por el fabricante del hardware de la máquina. Para poder modificar el KEK es necesaria una firma válida de la PK.

KEK: Es necesaria una firma válida de la "Key Exchange Key" para actualizar la base de datos de firmas.

db: La base de datos de firmas (Signature Database) contiene certificados bien conocidos, firmas o códigos hash de archivos binarios. El firmware solo ejecuta los ficheros binarios que se puedan verificar usando la base de datos. Se necesita una firma válida del KEK para poder actualizar la Signature Database.

dbx: La base de datos de firmas prohibidas (Forbidden Signatures Database) es lo opuesto de 'db'. Básicamente se trata de una lista negra de certificados, firmas y códigos hash. Si un archivo binario casa con cualquiera de las entradas en ella no se podrá ejecutar. Se necesita una firma válida del KEK para poder actualizar la Forbidden Signature Database.

MOK: Claves del propietario de la máquina (Machine Owner Keys). Unas base de datos extra de certificados o códigos hash que usa MokManager. Un usuario puede usar MokManager de modo interactivo durante el arranque para actualizar MOK.

Ver también

SDB:Instalar openSUSE con UEFI y Arranque seguro
Identificador universalmente único (universally unique identifier o UUID) en la Wikipedia.
Interfaz Extensible del Firmware (Extensible Firmware Interface o EFI), en la Wikipedia