Publication de Coreboot 4.17

La version 4.17 du projet CoreBoot a été publiée, développant une alternative libre aux firmwares propriétaires et aux BIOS. Le code du projet est distribué sous la licence GPLv2. 150 développeurs ont participé à la création de cette nouvelle version, apportant plus de 1300 modifications.

Principales modifications :

• Une vulnérabilité (CVE-2022-29264) a été corrigée, se manifestant dans les versions CoreBoot de 4.13 à 4.16, permettant l'exécution de code au niveau SMM (System Management Mode) sur des systèmes avec un AP (Application Processor), avec un niveau de priorité supérieur (Ring -2) à celui de l'hyperviseur et du niveau de protection zéro, ayant un accès illimité à toute la mémoire. Ce problème était causé par une invocation incorrecte du gestionnaire SMI dans le module smm_module_loader.
• Support ajouté pour 12 cartes mères, dont 5 sont utilisées sur des appareils avec Chrome OS ou sur serveurs Google. Parmi les cartes non liées à Google :
  • Clevo L140MU / L141MU / L142MU
  • Dell Precision T1650
  • Station de travail HP Z220 CMT
  • Star Labs LabTop Mk III (i7-8550u), LabTop Mk IV (i3-10110U, i7-10710U), Lite Mk III (N5000) et Lite Mk IV (N5030).
• Le support pour les cartes mères Google Deltan et Deltaur a été interrompu.
• Un nouveau payload coreDOOM a été ajouté, permettant de lancer le jeu DOOM depuis Coreboot. Le projet utilise du code doomgeneric, porté sur libpayload. Un framebuffer linéaire Coreboot est utilisé pour l'affichage, et les fichiers WAD contenant les ressources du jeu sont chargés depuis le CBFS.
• Les composants payload SeaBIOS 1.16.0 et iPXE 2022.1 ont été mis à jour.
• Un mode SeaGRUB (GRUB2 au-dessus de SeaBIOS) a été ajouté, permettant d'utiliser les appels de rappel fournis par SeaBIOS dans GRUB2, par exemple pour accéder au matériel, qui n'est pas accessible depuis le payload GRUB2.
• Une protection contre l'attaque SinkHole a été ajoutée, permettant l'exécution de code au niveau SMM (System Management Mode).
• Une fonctionnalité intégrée de génération de tables de pages de mémoire statiques à partir de fichiers assembleurs a été mise en œuvre, sans nécessiter l'appel d'utilitaires tiers.
• L'enregistrement d'informations de débogage dans la console CBMEMC depuis les gestionnaires SMI est autorisé lors de l'utilisation de DEBUG_SMI.
• Le système de gestion des initialisations CBMEM a été modifié, remplaçant les gestionnaires liés aux étapes *_CBMEM_INIT_HOOK par deux gestionnaires CBMEM_CREATION_HOOK (utilisé à la phase initiale, créant cbmem) et CBMEM_READY_HOOK (utilisé à toutes les phases où cbmem est déjà créé).
• Le support de PSB (Platform Secure Boot) a été ajouté, activé par le processeur PSP (Platform Security Processor) pour vérifier l'intégrité du BIOS par signature numérique.
• Une implémentation propre du gestionnaire de débogage des données, transférées depuis le FSP (FSP Debug Handler), a été ajoutée.
• Fonctions TIS spécifiques aux fabricants ajoutées (TPM Interface Specification) pour lire et écrire directement dans les registres TPM (Trusted Platform Module) — tis_vendor_read() et tis_vendor_write().
• Support de l'interception des déréférencements de pointeurs nuls via des registres de débogage ajouté.
• Détection des appareils i2c mise en œuvre, facilitant le travail avec des cartes équipées de pavés tactiles ou d'écrans tactiles de différents fabricants.
• Possibilité d'enregistrement des données temporelles au format adapté à la génération de graphiques FlameGraph, montrant clairement le temps consacré à différentes étapes du démarrage ajoutée.
• Une option a été ajoutée à l'outil cbmem pour inclure dans la table cbmem un « timestamp » temporel depuis l'espace utilisateur, permettant de refléter dans cbmem les événements se produisant après CoreBoot.

Il convient également de noter la publication d'une lettre ouverte par la fondation OSFF (Open-Source Firmware Foundation) à l'intention d'Intel, proposant de rendre les ensembles de support de firmware (FSP, Firmware Support Package) plus modulaires et de commencer à publier la documentation liée à l'initialisation des SoC Intel. L'absence de code FSP complique considérablement la création de firmwares ouverts et entrave la promotion des projets Coreboot, U-Boot et LinuxBoot sur le matériel Intel. Une initiative similaire antérieure a été couronnée de succès, et Intel a ouvert le code des firmwares demandés par la communauté pour le bloc PSE (Programmable Services Engine).

Source : opennet.ru