Coreboot 4.17 lançado

Foi publicado o lançamento do projeto CoreBoot 4.17, no âmbito do qual está sendo desenvolvida uma alternativa gratuita ao firmware proprietário e BIOS. O código do projeto é distribuído sob a licença GPLv2. Na criação da nova versão participaram 150 desenvolvedores, que prepararam mais de 1300 alterações.

Grandes mudanças:

  • Uma vulnerabilidade (CVE-2022-29264) que apareceu nas versões 4.13 a 4.16 do CoreBoot foi corrigida e permite que o código seja executado em sistemas com AP (Application Processor) no nível SMM (System Management Mode), que tem maior prioridade ( Anel -2) que o modo hipervisor e anel zero de proteção, além de ter acesso ilimitado a toda a memória. O problema é causado por uma chamada incorreta ao manipulador SMI no módulo smm_module_loader.
  • Adicionado suporte para 12 placas-mãe, 5 das quais são usadas em dispositivos com Chrome OS ou em servidores Google. Entre as taxas que não são do Google:
    • 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 placas-mãe Google Deltan e Deltaur foi descontinuado.
  • Adicionada uma nova carga útil coreDOOM, permitindo que você inicie o jogo DOOM a partir do Coreboot. O projeto usa código doomgeneric, portado para libpayload. O framebuffer linear Coreboot é usado para saída e os arquivos WAD com recursos do jogo são carregados do CBFS.
  • Componentes de carga útil atualizados SeaBIOS 1.16.0 e iPXE 2022.1.
  • Adicionado o modo SeaGRUB (GRUB2 sobre SeaBIOS), que permite ao GRUB2 usar as chamadas de retorno fornecidas pelo SeaBIOS, por exemplo, para acessar equipamentos que não são acessíveis a partir da carga útil do GRUB2.
  • Adicionada proteção contra o ataque SinkHole, que permite que o código seja executado no nível SMM (System Management Mode).
  • Implementada uma capacidade integrada de gerar tabelas estáticas de páginas de memória a partir de arquivos assembly, sem a necessidade de chamar utilitários de terceiros.
  • Permitir gravar informações de depuração no console CBMEMC a partir de manipuladores SMI ao usar DEBUG_SMI.
  • O sistema de manipuladores de inicialização do CBMEM foi alterado; em vez dos manipuladores *_CBMEM_INIT_HOOK vinculados aos estágios, são propostos dois manipuladores: CBMEM_CREATION_HOOK (usado no estágio inicial que cria o cbmem) e CBMEM_READY_HOOK (usado em quaisquer estágios em que o cbmem já tenha sido criada).
  • Adicionado suporte para PSB (Platform Secure Boot), ativado pelo processador PSP (Platform Security Processor) para verificar a integridade do BIOS usando uma assinatura digital.
  • Adicionada nossa própria implementação de um manipulador para depuração de dados transferidos do FSP (FSP Debug Handler).
  • Adicionadas funções TIS (TPM Interface Specification) específicas do fornecedor para leitura e gravação diretamente de registros TPM (Trusted Platform Module) - tis_vendor_read() e tis_vendor_write().
  • Adicionado suporte para interceptar desreferências de ponteiro nulo por meio de registros de depuração.
  • Implementada detecção de dispositivos i2c, facilitando o trabalho com placas equipadas com touchpads ou telas sensíveis ao toque de diversos fabricantes.
  • Adicionada a capacidade de salvar dados de tempo em um formato adequado para gerar gráficos FlameGraph, que demonstram claramente quanto tempo é gasto nas diferentes etapas do lançamento.
  • Foi adicionada uma opção ao utilitário cbmem para adicionar um “timestamp” de tempo do espaço do usuário à tabela cbmem, o que possibilita refletir eventos em etapas executadas após o CoreBoot no cbmem.

Adicionalmente, podemos notar a publicação pela OSFF (Open-Source Firmware Foundation) de uma carta aberta à Intel, que propõe tornar os pacotes de suporte de firmware (FSP, Firmware Support Package) mais modulares e começar a publicar documentação relacionada à inicialização do Intel SoC . A falta de código FSP complica significativamente a criação de firmware aberto e impede o avanço dos projetos Coreboot, U-Boot e LinuxBoot em hardware Intel. Anteriormente, uma iniciativa semelhante foi bem-sucedida e a Intel abriu o código para o firmware do bloco PSE (Programmable Services Engine) solicitado pela comunidade.

Fonte: opennet.ru

Adicionar um comentário