Utgivelse av Coreboot 4.17

CoreBoot 4.17 er blitt utgitt, et prosjekt som utvikler et fritt alternativ til proprietære fastvare og BIOS. Koden for prosjektet er lisensiert under GPLv2. 150 utviklere har deltatt i utviklingen av den nye versjonen, som har forberedt mer enn 1300 endringer.

Hovedendringer:

• En sårbarhet (CVE-2022-29264) som ble funnet i CoreBoot-utgivelser fra 4.13 til 4.16, er blitt rettet. Denne sårbarheten tillot kjøring av kode på nivået SMM (System Management Mode) på systemer med AP (Application Processor), noe som gir høyere prioritet (Ring -2) enn hypervisor-moden og null beskyttelsesring, med uhindret tilgang til all minne. Problemet ble forårsaket av en feilaktig kall til SMI-behandleren i modulen smm_module_loader.
• Støtte for 12 hovedkort er lagt til, 5 av dem brukes på enheter med Chrome OS eller til servere Google. Blant de som ikke er relatert til Google-kortene:
  • 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) og Lite Mk IV (N5030).
• Støtte for hovedkortene Google Deltan og Deltaur er avsluttet.
• En ny payload coreDOOM er lagt til, som lar deg kjøre DOOM-spillet fra Coreboot. I prosjektet er koden doomgeneric brukt, portert til libpayload. For utdata brukes Coreboot-lineær rammebuffer, og WAD-filer med spillekilder lastes fra CBFS.
• Payload-komponentene SeaBIOS 1.16.0 og iPXE 2022.1 er oppdatert.
• SeaGRUB-modus (GRUB2 ovenfor SeaBIOS) er lagt til, som lar GRUB2 bruke de callback-kallene som SeaBIOS tilbyr, for eksempel for å få tilgang til maskinvare som ikke er tilgjengelig fra GRUB2-payload.
• Beskyttelse mot SinkHole-angrep er lagt til, som tillater kjøring av kode på SMM-nivå (System Management Mode).
• En innebygd funksjon for å generere statiske sider minnetabeller fra assemblerfiler uten behov for å kalle eksterne verktøy, er implementert.
• Skriving av feilsøkingsinformasjon til konsollen CBMEMC fra SMI-behandlere når DEBUG_SMI brukes, er tillatt.
• Systemet for behandlingen av CBMEM-initialisering er endret; i stedet for foreskrevne behandlere til stadiene *_CBMEM_INIT_HOOK, er to behandlere CBMEM_CREATION_HOOK (brukes i den innledende fasen som oppretter cbmem) og CBMEM_READY_HOOK (brukes i alle stadier når cbmem allerede er opprettet) foreslått.
• Støtte for PSB (Platform Secure Boot) er lagt til, aktivert av prosessoren PSP (Platform Security Processor) for å verifisere integriteten til BIOS via digitalt signatur.
• En egen implementering av debug-datahåndtereren som sendes fra FSP (FSP Debug Handler) er lagt til.
• TIS-funksjoner spesifik for produsenter (TPM Interface Specification) for å lese og skrive direkte fra registre i TPM (Trusted Platform Module) — tis_vendor_read() og tis_vendor_write().
• Støtte for å fange opp avdereferering av nullpekere via feilsøkingsregistre er lagt til.
• Implementert deteksjon av i2c-enheter, som forenkler arbeidet med brett utstyrt med berøringsplater eller berøringsskjermer fra ulike produsenter.
• Mulighet for å lagre tidsdata i et format som er egnet for å generere FlameGraph-diagrammer, tydelig som viser hvor mye tid som brukes på ulike faser av oppstarten, er lagt til.
• Til cbmem-verktøyet er det lagt til en opsjon for å legge ‘timestamp’ fra brukerrommet inn i cbmem-tabellen, noe som gir mulighet til å reflektere hendelser i cbmem under faser som utføres etter CoreBoot.

I tillegg kan det nevnes at OSFF (Open-Source Firmware Foundation) har publisert et åpent brev til selskapet Intel, der det foreslås å gjøre støttepakker (FSP, Firmware Support Package) mer modulære og begynne å publisere dokumentasjon relatert til initializing av Intel SoC. Mangel på FSP-kode kompliserer betydelig utviklingen av åpne fastvarer og hindrer fremdriften av prosjektene Coreboot, U-Boot og LinuxBoot på Intel-utstyr. På forhånd har en lignende initiativ vært vellykket, og selskapet Intel har åpnet koden for de etterspurte fastvarene fra PSE (Programmable Services Engine) fellesskapet.

Kilde: opennet.ru