Lanzamiento de Coreboot 4.17

Se ha publicado el lanzamiento del proyecto CoreBoot 4.17, en cuyo marco se está desarrollando una alternativa gratuita al firmware y BIOS propietarios. El código del proyecto se distribuye bajo la licencia GPLv2. En la creación de la nueva versión participaron 150 desarrolladores, que prepararon más de 1300 cambios.

Cambios importantes:

• Se ha solucionado una vulnerabilidad (CVE-2022-29264) que apareció en las versiones CoreBoot 4.13 a 4.16 y permite ejecutar código en sistemas con AP (Procesador de aplicaciones) en el nivel SMM (Modo de administración del sistema), que tiene una prioridad más alta ( Ring -2) que el modo hipervisor y un 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.
• Se agregó soporte para 12 placas base, 5 de las cuales se utilizan en dispositivos con Chrome OS o en servidores de Google. Entre las tarifas ajenas a Google:
  • Clevo L140MU / L141MU / L142MU
  • Dell Precision 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 ha interrumpido el soporte para las placas base Google Deltan y Deltaur.
• Se agregó una nueva carga útil coreDOOM, que te permite iniciar el juego DOOM desde Coreboot. El proyecto utiliza código doomgeneric, portado a libpayload. El framebuffer lineal 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 a GRUB2 usar las llamadas de devolución de llamada proporcionadas por SeaBIOS, por ejemplo, para acceder a equipos a los que no se puede acceder desde la carga útil de GRUB2.
• Se agregó protección contra el ataque SinkHole, que permite que el código se ejecute en el nivel SMM (Modo de administración del sistema).
• Se implementó una capacidad incorporada para generar tablas estáticas de páginas de memoria a partir de archivos ensamblados, sin la necesidad de llamar a utilidades de terceros.
• Permitir escribir información de depuración en la consola CBMEMC desde los controladores SMI cuando se usa DEBUG_SMI.
• El sistema de controladores de inicialización de CBMEM ha sido cambiado; en lugar de los controladores *_CBMEM_INIT_HOOK vinculados a las etapas, se proponen dos controladores: CBMEM_CREATION_HOOK (usado en la etapa inicial que crea cbmem) y CBMEM_READY_HOOK (usado en cualquier etapa en la que cbmem ya haya sido creado).
• Se agregó soporte para PSB (Platform Secure Boot), activado por el procesador PSP (Platform Security Processor) para verificar la integridad del BIOS mediante una firma digital.
• Se agregó nuestra propia implementación de un controlador para depurar datos transferidos desde FSP (FSP Debug Handler).
• Se agregaron funciones TIS (especificación de interfaz TPM) específicas del proveedor para leer y escribir directamente desde registros TPM (módulo de plataforma confiable): tis_vendor_read() y tis_vendor_write().
• Se agregó soporte para interceptar desreferencias de puntero nulo mediante registros de depuración.
• Implementé la detección de dispositivos i2c, facilitando el trabajo con placas equipadas con touchpads o pantallas táctiles de diferentes fabricantes.
• 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 ha agregado una opción a la utilidad cbmem para agregar una "marca de tiempo" del espacio del usuario a la tabla cbmem, lo que permite reflejar eventos en etapas realizadas después de CoreBoot en cbmem.

Además, podemos destacar la publicación por parte de la OSFF (Open-Source Firmware Foundation) de una carta abierta a Intel, que propone hacer más modulares los paquetes de soporte de firmware (FSP, Firmware Support Package) y comenzar a publicar documentación relacionada con la inicialización del SoC Intel. . La falta de código FSP complica significativamente la creación de firmware abierto e impide el avance de proyectos Coreboot, U-Boot y LinuxBoot en hardware Intel. Anteriormente, una iniciativa similar tuvo éxito e Intel abrió el código para el firmware del bloque PSE (Programmable Services Engine) solicitado por la comunidad.

Fuente: opennet.ru