nmbl (No More Boot Loader): usar o kernel no lugar do bootloader

• A equipe de engenharia de bootloaders da Red Hat está desenvolvendo uma nova abordagem para substituir o bootloader GRUB
• Propõe o nmbl (no more boot loader), uma solução em espaço de usuário baseada em Linux, rápida e segura
• Problemas do bootloader GRUB
  • O GRUB é um bootloader poderoso e flexível, usado em várias arquiteturas (x86_64, aarch64, ppc64le OpenFirmware)
  • Porém, sua funcionalidade complexa dificulta a manutenção e muitas vezes duplica recursos do kernel Linux ou fica para trás em relação a ele
  • Além disso, acaba gerando muitas vulnerabilidades de segurança
• Vantagens do kernel Linux
  • O kernel Linux tem uma grande base de desenvolvedores, o que permite evolução rápida de recursos e resposta a vulnerabilidades
  • A revisão geral também é feita de forma mais rigorosa
• Nova solução: usar o kernel como bootloader
  • É carregado pelo EFI stub no UEFI e empacotado como uma Unified Kernel Image (UKI)
  • O kernel, o initramfs e a linha de comando do kernel incluem tudo o que é necessário para alcançar o destino final do boot
  • Todos os drivers necessários, suporte a sistemas de arquivos e rede já estão embutidos, evitando duplicação de código

[xguru]

Comentários do Hacker News

• Uso UEFI há 10 anos. O tempo de boot fica um pouco menor, mas o bootloader tem várias vantagens

  • Permite fazer dual boot com Windows com facilidade
  • Dá para editar a cmdline do kernel para resolver problemas de inicialização
  • Dá para escolher facilmente entre vários kernels e imagens initrd
  • Permite acessar facilmente o menu de configurações do UEFI
  • Permite inicializar outros aplicativos EFI

• O bootloader do FreeBSD consegue inicializar sem initramfs. Precisamos de um bootloader mais inteligente

  • Ele entende ZFS e pode carregar antecipadamente os módulos necessários
  • Ele entende dependências entre módulos e pode carregar antecipadamente todos os módulos necessários

• Há muitos mal-entendidos sobre as capacidades e limitações do ambiente UEFI. As pessoas estão entendendo errado o objetivo real do projeto

  • O texto crítico do Lennart levanta preocupações mais interessantes

• Isso lembra o MILO, que era usado para inicializar Linux em sistemas DEC Alpha nos anos 90

  • É necessário um bootloader intermediário, com um ciclo de lançamento voltado para estabilidade
  • É necessária uma camada de menu/configuração orientada a dados

• Antes usei Linux+Coreboot em um Chromebook. Por causa de bugs de driver na BIOS UEFI Tianocore, acabei usando Linux diretamente

  • Escrevi uma TUI em Rust para montar todas as partições e fazer kexec da imagem do kernel
  • Não acho que seja preciso duplicar todos os drivers

• É melhor aproveitar mais os recursos do UEFI e do Linux. O ZFSBootMenu já fornece um aplicativo EFI há 4 anos

  • O boot do kernel no primeiro estágio leva cerca de 1,5 a 2 segundos

• Há preocupação com problemas de compatibilidade com kexec

  • Por exemplo, o módulo da NVidia precisa ser descarregado antes do kexec
  • Também há problemas com ACPI e compatibilidade
  • Imagino que o mecanismo do kexec tenha sido projetado para suportar várias versões de kernel

• Fazer o EFI stub configurar multiboot, kernel e initrd, e depois saltar para eles, é simples

  • Não é necessário que um loader intermediário fique grande e complexo demais
  • Incluir um Linux inteiro só para evitar a API do UEFI e um ambiente de programação diferente é desnecessário

• Fico me perguntando se a solução proposta conseguirá lidar com boot multi-OS

  • O grub consegue inicializar Linux, Windows e até um terceiro sistema operacional
  • Há receio de que a solução da Red Hat fique restrita apenas a uso comercial
  • É difícil entender que problema isso resolve em sistemas que só reiniciam uma ou duas vezes por ano

• Não entendo por que usar essa solução em vez de plain EFISTUB

  • Uso EFISTUB no Arch e, para iniciar o Windows, uso o menu da BIOS
  • Não vejo a vantagem de um bootloader baseado em Linux