Lansering av Coreboot 4.17

Utgivningen av CoreBoot 4.17 har offentliggjorts, ett projekt som utvecklar ett fritt alternativ till proprietära firmware och BIOS. Projektets kod distribueras under GPLv2-licensen. I skapandet av den nya versionen deltog 150 utvecklare som förberedde mer än 1300 förändringar.

Huvudsakliga förändringar:

• Sårbarheten (CVE-2022-29264) har åtgärdats, som visar sig i CoreBoot-versioner från 4.13 till 4.16 och tillåter att köra kod på AP (Application Processor) på SMM (System Management Mode)-nivå, vilket är mer prioriterat (Ring -2) än hypervisorläge och null ring skydd, och har obegränsad tillgång till allt minne. Problemet orsakades av en felaktig anropning av SMI-hanteraren i smm_module_loader-modulen.
• Stödet för 12 moderkort har lagts till, varav 5 används på enheter med Chrome OS eller på servrar Google. Bland de moderkort som inte är relaterade till 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) och Lite Mk IV (N5030).
• Stödet för moderkorten Google Deltan och Deltaur har upphört.
• En ny payload coreDOOM har lagts till, som gör det möjligt att köra spelet DOOM från Coreboot. Projektet använder koden doomgeneric, portad till libpayload. För utmatning används Coreboot's linjära framebuffer, och WAD-filer med spelresurser laddas från CBFS.
• Payload-komponenterna SeaBIOS 1.16.0 och iPXE 2022.1 har uppdaterats.
• SeaGRUB-läget (GRUB2 ovanpå SeaBIOS) har lagts till, vilket gör det möjligt att använda SeaBIOS callback-anrop i GRUB2, till exempel för att komma åt hårdvara som GRUB2's payload inte har tillgång till.
• Skydd mot SinkHole-attacken har lagts till, vilket möjliggör kodexekvering på SMM (System Management Mode)-nivå.
• En inbyggd möjlighet att generera statiska minnestabeller från assemblerfiler har implementerats, utan behov av att anropa externa verktyg.
• Skrivning av felsökningsinformation till CBMEMC-konsolen från SMI-hanterare är tillåten vid användning av DEBUG_SMI.
• Systemet för initieringshanterare av CBMEM har ändrats, istället för hanterare knutna till faser har två hanterare föreslagits: CBMEM_CREATION_HOOK (används i det tidigaste stadiet som skapar cbmem) och CBMEM_READY_HOOK (används vid alla stadier där cbmem redan har skapats).
• Stödet för PSB (Platform Secure Boot) har lagts till, aktiveras av PSP (Platform Security Processor) för att verifiera BIOS-integritet med digital signatur.
• En egen implementering av hanteraren för felsökningsdata som överförs från FSP (FSP Debug Handler) har lagts till.
• Specifika för tillverkare av TIS-funktioner (TPM Interface Specification) för att läsa och skriva direkt från TPM-register (Trusted Platform Module) har lagts till — tis_vendor_read() och tis_vendor_write().
• Stöd för att fånga avindirektioner för nullpekare via debugregister har lagts till.
• Implementering av I2C-enhetsidentifiering som förenklar arbetet med kort som har pekskärmar eller touchpads från olika tillverkare.
• Möjlighet att spara tidsdata i ett format som är lämpligt för att generera FlameGraph-diagram, vilket tydligt visar hur mycket tid som spenderas i olika faser av uppstarten har lagts till.
• En alternativ för att lägga till tidsstämpel från användarrummet till cbmem-tabellen har lagts till i cbmem-verktyget, vilket gör att man kan reflektera händelser i cbmem som äger rum efter CoreBoot.

Dessutom kan nämnas att OSFF (Open-Source Firmware Foundation) har publicerat ett öppet brev till företaget Intel, där det föreslås att göra firmware-supportpaket (FSP, Firmware Support Package) mer modulära och börja publicera dokumentation relaterad till initialisering av Intel SoC. Bristen på FSP-kod gör det avsevärt svårt att skapa öppna firmwares och hindrar framstegen för Coreboot-, U-Boot- och LinuxBoot-projekt på Intel-utrustning. Tidigare har en liknande initiativ varit framgångsrik och Intel har öppnat koden för de firmwares som begärts av samhällen för PSE (Programmable Services Engine).

Källa: opennet.ru