Lançamento do Coreboot 4.17

Foi lançado o projeto CoreBoot 4.17, que oferece uma alternativa livre para firmware e BIOS proprietários. O código do projeto é distribuído sob a licença GPLv2. A nova versão foi desenvolvida por 150 programadores, que implementaram mais de 1300 alterações.

Principais mudanças:

• Foi corrigida uma vulnerabilidade (CVE-2022-29264) que afeta as versões do CoreBoot de 4.13 a 4.16, permitindo que, em sistemas com AP (Processador de Aplicações), seja executado código no nível SMM (Modo de Gerenciamento de Sistema), que possui prioridade maior (Anel -2) que o modo hipervisor e o anel zero de proteção, tendo acesso irrestrito a toda a memória. O problema foi causado por uma chamada incorreta do manipulador SMI no módulo smm_module_loader.
• Adicionada a compatibilidade com 12 placas-mãe, 5 das quais são usadas em dispositivos com Chrome OS ou em servidores Google. Entre as placas não relacionadas ao Google estão:
  • Clevo L140MU / L141MU / L142MU
  • Dell Precision T1650
  • Estação de Trabalho HP Z220 CMT
  • Star Labs LabTop Mk III (i7-8550u), LabTop Mk IV (i3-10110U, i7-10710U), Lite Mk III (N5000) e Lite Mk IV (N5030).
• O suporte para as placas-mãe Google Deltan e Deltaur foi encerrado.
• Adicionado um novo payload coreDOOM, que permite executar o jogo DOOM a partir do Coreboot. O projeto utiliza o código doomgeneric, portado para libpayload. Um framebuffer linear do Coreboot é usado para a saída, e os arquivos WAD com os recursos do jogo são carregados a partir do CBFS.
• As componentes do payload foram atualizadas para SeaBIOS 1.16.0 e iPXE 2022.1.
• Adicionado o modo SeaGRUB (GRUB2 sobre o SeaBIOS), que permite ao GRUB2 utilizar chamadas de retorno fornecidas pelo SeaBIOS, por exemplo, para acessar hardware ao qual o payload do GRUB2 não tem acesso.
• Adicionada proteção contra o ataque SinkHole, que permite a execução de código no nível SMM (Modo de Gerenciamento de Sistema).
• Implementada uma capacidade embutida para gerar tabelas de páginas de memória estáticas a partir de arquivos assembly, sem a necessidade de chamar utilitários externos.
• A gravação de informações de depuração foi permitida no console CBMEMC a partir dos manipuladores SMI ao utilizar DEBUG_SMI.
• O sistema de manipuladores de inicialização CBMEM foi alterado. Em vez dos manipuladores vinculados às etapas *_CBMEM_INIT_HOOK, foram propostos dois manipuladores CBMEM_CREATION_HOOK (usado na fase inicial que cria o cbmem) e CBMEM_READY_HOOK (usado em qualquer estágio em que o cbmem já foi criado).
• Adicionada a compatibilidade com PSB (Platform Secure Boot), ativada pelo processador PSP (Platform Security Processor) para verificar a integridade do BIOS por meio de assinatura digital.
• Adicionada uma implementação própria do manipulador de dados de depuração, transmitida a partir do FSP (FSP Debug Handler).
• Funções específicas do fabricante TIS foram adicionadas (Especificação de Interface TPM) para leitura e gravação diretamente dos registros TPM (Trusted Platform Module) — tis_vendor_read() e tis_vendor_write().
• Suporte adicionado para interceptação de desreferências de ponteiros nulos através de registros de depuração.
• Implementação de detecção de dispositivos i2c, facilitando o trabalho com placas equipadas com touchpads ou telas sensíveis ao toque de diferentes fabricantes.
• Adicionada a capacidade de salvar dados de tempo em um formato adequado para a geração de gráficos FlameGraph, demonstrando visualmente quanto tempo é gasto em diferentes etapas de inicialização.
• Uma opção foi adicionada ao utilitário cbmem para incluir na tabela cbmem um 'timestamp' do tempo no espaço do usuário, permitindo refletir eventos em cbmem nas etapas executadas após o CoreBoot.

Adicionalmente, destaca-se a publicação de uma carta aberta pela OSFF (Open-Source Firmware Foundation) à Intel, propondo tornar os pacotes de suporte de firmware (FSP, Firmware Support Package) mais modulares e começar a publicar documentação relacionada à inicialização do SoC Intel. A ausência do código FSP dificulta significativamente a criação de firmwares abertos e prejudica o avanço dos projetos Coreboot, U-Boot e LinuxBoot em hardware Intel. Uma iniciativa semelhante anterior foi bem-sucedida e a Intel abriu o código de firmwares do bloco PSE (Programmable Services Engine) solicitados pela comunidade.

Fonte: opennet.ru