Lanzamiento de Coreboot 4.17

Se ha publicado el lanzamiento del proyecto CoreBoot 4.17, en el cual se desarrolla una alternativa libre a los firmware y BIOS propietarios. El código del proyecto se distribuye bajo la licencia GPLv2. En la creación de esta nueva versión participaron 150 desarrolladores, quienes prepararon más de 1300 cambios.

Principales cambios:

• Se ha solucionado una vulnerabilidad (CVE-2022-29264) que se presenta en las versiones de CoreBoot desde 4.13 hasta 4.16, permitiendo en sistemas con AP (Procesador de Aplicaciones) ejecutar código a nivel SMM (Modo de Gestión del Sistema), que tiene una prioridad mayor (Ring -2) que el modo hipervisor y el anillo cero de protección, y teniendo acceso irrestricto a toda la memoria. El problema fue causado por una llamada incorrecta al controlador SMI en el módulo smm_module_loader.
• Se ha añadido soporte para 12 placas base, 5 de las cuales se utilizan en dispositivos con Chrome OS o en como en entornos de nube públicos o privados. Google. Entre las placas no relacionadas con Google:
  • Clevo L140MU / L141MU / L142MU
  • Dell Precision T1650
  • HP Z220 CMT Workstation
  • Star Labs LabTop Mk III (i7-8550u), LabTop Mk IV (i3-10110U, i7-10710U), Lite Mk III (N5000) y Lite Mk IV (N5030).
• Se ha dejado de dar soporte a las placas base Google Deltan y Deltaur.
• Se ha añadido un nuevo payload coreDOOM, que permite iniciar el juego DOOM desde Coreboot. En el proyecto se utilizó el código doomgeneric, portado a libpayload. Para la salida se utiliza el framebuffer lineal de Coreboot, y los archivos WAD con recursos del juego se cargan desde CBFS.
• Se han actualizado los componentes de payload SeaBIOS 1.16.0 e iPXE 2022.1.
• Se ha añadido el modo SeaGRUB (GRUB2 sobre SeaBIOS), que permite en GRUB2 utilizar las llamadas de devolución proporcionadas por SeaBIOS, por ejemplo, para acceder a hardware al que no hay acceso desde el payload GRUB2.
• Se ha añadido protección contra el ataque SinkHole, que permite ejecutar código a nivel SMM (Modo de Gestión del Sistema).
• Se ha implementado una función incorporada de generación de tablas de páginas de memoria estáticas a partir de archivos assembler, sin necesidad de invocar utilidades externas.
• Se ha permitido la escritura de información de depuración en la consola CBMEMC desde los controladores SMI al utilizar DEBUG_SMI.
• Se ha modificado el sistema de controladores de inicialización de CBMEM, en lugar de los controladores vinculados a etapas *_CBMEM_INIT_HOOK, se han propuesto dos controladores CBMEM_CREATION_HOOK (utilizado en la etapa inicial que crea cbmem) y CBMEM_READY_HOOK (utilizado en cualquier etapa en la que cbmem ya está creado).
• Se ha añadido soporte para PSB (Platform Secure Boot), activado por el procesador PSP (Platform Security Processor) para verificar la integridad del BIOS a través de una firma digital.
• Se ha añadido una implementación propia del controlador de datos de depuración, que se transmiten desde FSP (FSP Debug Handler).
• Se han añadido funciones TIS específicas de fabricantes (Especificación de Interfaz TPM) para leer y escribir directamente desde los registros TPM (Módulo de Plataforma de Confianza) — tis_vendor_read() y tis_vendor_write().
• Se ha agregado soporte para la interceptación de desreferencias de punteros nulos a través de registros de depuración.
• Se ha implementado la detección de dispositivos i2c, lo que facilita el trabajo con placas equipadas con paneles táctiles o pantallas táctiles de diferentes fabricantes.
• Se ha añadido la capacidad de guardar datos de tiempo en un formato adecuado para la generación de gráficos FlameGraph, que muestran claramente cuánto tiempo se dedica a diferentes etapas del arranque.
• Se ha añadido a la utilidad cbmem la opción para agregar en la tabla cbmem una 'marca de tiempo' del espacio de usuario, lo que permite reflejar en cbmem eventos en etapas que se realizan después de CoreBoot.

Además, se puede destacar la publicación de una carta abierta por parte de la fundación OSFF (Open-Source Firmware Foundation) a la empresa Intel, en la que se propone hacer más modulares los conjuntos de soporte de firmware (FSP, Paquete de Soporte de Firmware) y comenzar a publicar documentación relacionada con la inicialización de SoC Intel. La falta de código FSP dificulta significativamente la creación de firmwares abiertos y obstaculiza el avance de proyectos como Coreboot, U-Boot y LinuxBoot en hardware de Intel. Anteriormente, una iniciativa similar tuvo éxito y la empresa Intel abrió el código de los firmwares solicitados por la comunidad del bloque PSE (Engine de Servicios Programables).

Fuente: opennet.ru