Se ha publicado el lanzamiento del proyecto CoreBoot 4.17, dentro del cual se está desarrollando una alternativa libre al firmware propietario y BIOS.
Desde el lanzamiento de la versión 4.16, se realizaron más de 1300 confirmaciones nuevas de alrededor de 150 colaboradores. De esas personas, aproximadamente 15 eran contribuyentes por primera vez.
Principales novedades de CoreBoot 4.17
En esta nueva versión que se presenta, podremos encontrar que se agregaron funciones TIS (Especificación de interfaz TPM) específicas del proveedor para leer y escribir directamente desde los registros TPM (Módulo de plataforma confiable): tis_vendor_read() y tis_vendor_write().
Otro de los cambios que se destaca es que se agregó el soporte para interceptar desreferencias de puntero nulo a través de registros de depuración y que ademas se ha implementado la detección de dispositivos i2c para facilitar el trabajo con lacas equipadas con touchpads o pantallas táctiles de diferentes fabricantes.
Ademas de ello, se destaca que se agregó la capacidad de guardar datos de tiempo en un formato adecuado para generar gráficos FlameGraph que demuestran claramente cuánto tiempo se dedica a las diferentes etapas del lanzamiento.
Se agregó una opción a la utilidad cbmem para agregar tiempo desde el espacio del usuario a la tabla de «marca de tiempo» de cbmem, lo que hace posible reflejar eventos en cbmem en etapas ejecutadas después de CoreBoot.
Se ha implementado la capacidad integrada para generar tablas de páginas de memoria estáticas a partir de archivos ensambladores, sin necesidad de llamar a utilidades de terceros.
Por otra parte, tambien se destaca que se corrigió una vulnerabilidad (CVE-2022-29264) que se manifestó en las versiones de CoreBoot de la 4.13 a la 4.16 y permitía en los sistemas con AP (Application Processor) ejecutar código en el nivel SMM (System Management Mode), que tiene una prioridad más alta (Ring -2) que el modo hipervisor y el anillo de protección cero, y tener acceso ilimitado a toda la memoria. El problema se debe a una llamada incorrecta al controlador SMI en el módulo smm_module_loader.
De los demás cambios que se destacan de esta nueva versión:
- Se permitió escribir información de depuración en la consola CBMEMC desde los controladores SMI cuando se usa DEBUG_SMI.
- Se ha cambiado el sistema de manejadores de inicialización CBMEM, en lugar de manejadores *_CBMEM_INIT_HOOK vinculados a etapas, se proponen dos manejadores CBMEM_CREATION_HOOK (usado en la etapa inicial que crea cbmem) y CBMEM_READY_HOOK (usado en cualquier etapa donde ya se haya creado cbmem).
- Se agregó soporte para PSB (Platform Secure Boot), activado por el PSP (Platform Security Processor) para verificar la integridad del BIOS mediante firma digital.
- Se agregó una implementación propia del controlador de datos de depuración pasado desde FSP (FSP Debug Handler).
- Se agregó soporte para 12 placas base, 5 de las cuales se usan en dispositivos Chrome OS o servidores de Google:
Clevo L140MU / L141MU / L142MU
Dell precisión T1650
Estación de trabajo HP Z220 CMT
Star Labs LabTop Mk III (i7-8550u), LabTop Mk IV (i3-10110U, i7-10710U), Lite Mk III (N5000) y Lite Mk IV (N5030). - Se eliminó el soporte para las placas base Google Deltan y Deltaur.
- Se agregó una nueva carga útil coreDOOM , que le permite ejecutar un juego DOOM desde Coreboot.
- El proyecto usa código doomgeneric portado a libpayload.
- El framebuffer lineal de Coreboot se utiliza para la salida y los archivos WAD con recursos del juego se cargan desde CBFS.
- Componentes de carga útil actualizados SeaBIOS 1.16.0 e iPXE 2022.1.
- Se agregó el modo SeaGRUB (GRUB2 sobre SeaBIOS), que permite que GRUB2 use las devoluciones de llamada proporcionadas por SeaBIOS, por ejemplo, para acceder a equipos a los que la carga útil de GRUB2 no tiene acceso.
- Se agregó protección contra el ataque SinkHole, que le permite ejecutar código en el nivel SMM (Modo de administración del sistema).
Adicionalmente, podemos señalar la publicación por parte de OSFF (Open-Source Firmware Foundation) de una carta abierta a Intel, en la que propone modularizar los paquetes de soporte de firmware (FSP, Firmware Support Package) y comenzar a publicar documentación relacionada con la inicialización de SoC Intel.
La falta de código FSP dificulta mucho la creación de firmware abierto y dificulta el progreso de los proyectos Coreboot, U-Boot y LinuxBoot en hardware Intel. Anteriormente, una iniciativa similar tuvo éxito e Intel abrió el código para el firmware PSE (Motor de servicios programables) solicitado por la comunidad.
Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.