Esse tipo de problema é inevitável. Ou, pelo menos, é duplamente provável . Quando as pessoas falam sobre grub como necessidade , elas quase sempre trazem coisas como manter a imagem do kernel em um disco criptografado ou chaves SecureBoot. Eles costumam dizer que você não poderia lidar com essas coisas de outra forma, que você precisa de um carregador intermediário em seu processo de inicialização para fazer a interface entre seu firmware e seu kernel.
Embora seja verdade que grub consiga ler muitos tipos diferentes de sistemas de arquivos, tenha suporte de rede embutido e suporte shims EFI SecureBoot, acho um pouco estranho que outros considerem que eles são bons coisas. Considero-os redundantes, excessivamente complicados e uma segunda superfície de ataque.
Era uma vez necessário - embora sempre tenha sido estúpido - já foi necessário para o firmware chamar um intermediário binário do carregador que poderia então chamar o kernel. Foi necessário porque o BIOS era muito antigo e estúpido para compreender qualquer kernel do sistema praticamente utilizável que você preferiria carregar. A idéia de um bootloader era apenas uma solução para o firmware estúpido em primeiro lugar.
Para máquinas típicas fabricadas a qualquer momento nos últimos cinco anos ou mais, esse não é mais o caso, embora praticamente todas as distribuições Linux ainda o façam por padrão. O BIOS está morto - o padrão (U) EFI praticamente o substituiu, e um firmware dessa variedade não tem problemas para invocar diretamente o kernel do seu sistema - não é necessário o bootloader. De fato, se você fosse compilar em seu initramfs, poderia simplesmente nomear sua imagem de kernel /boot/EFI/BOOT/BOOTX64.efi e seu computador iria inicializá-la automaticamente .
E todas as coisas sobre grub sendo necessárias para lidar com sistemas de arquivos criptografados e etc são besteiras, claras e simples. Do meu ponto de vista, quanto menos programas houver que possa desbloquear um disco bloqueado, mais seguro será o bloqueio. Então, se você mantivesse seu kernel em um sistema de arquivos simples - como o muito básico FAT exigido pela sua partição do sistema EFI - então o (U) EFI poderia carregá-lo e o kernel desbloquearia seu disco, é claro.
Você também pode autorretrato seu kernel do sistema e instale essas chaves na NVRAM do firmware para que o firmware valide diretamente o certificado da sua imagem do kernel a cada inicialização.
Você pode fazer isso sem grub - você pode fazer isso mais fácil sem grub .
Portanto, se você quiser se preocupar com a complexidade extra e com a superfície de ataque extra de um segundo kernel do sistema operacional, atualize seu grub chainloader imediatamente. Se você não fizer isso, você deve desinstalá-lo.
As respostas no site de Segurança da Informação parecem minimizar a vulnerabilidade envolvida com este problema. Eles dizem que não é um problema, porque você precisa de acesso físico à máquina para explorá-la, e que, se você tem isso, a máquina é sua de qualquer maneira.
Eu discordo. Se alguém conseguir acessar seu computador, desligá-lo e ligá-lo, contorne sua senha do menu de inicialização pressionando o botão backspace 28 vezes e depois terá acesso aos seus discos pela linha de comando