Usuários que possuem o Windows 11 em seus computadores estão experimentando uma dor de cabeça extra com problemas na hora de fazer dual boot com o o Linux por conta do Windows BitLocker da Microsoft.
Aumentar o uso do Windows BitLocker para criptografia de disco completo no Windows 10 e no Windows 11 está causando mais desafios para as distribuições Linux para oferecer suporte à funcionalidade de inicialização dupla para aqueles que desejam manter o Windows e o Linux nos mesmos dispositivos.
Os engenheiros da Fedora/Red Hat estão tocando o alarme sobre a inicialização dupla do Windows e do Linux. Segundo eles, este processo está se tornando muito mais complexo para suportar. Em particular, o BitLocker do Windows para criptografia de disco completo em que a chave de criptografia é lacrada usando o hardware TPM.
Windows BitLocker causa problemas para dual boot com Linux
Ao envolver o BitLocker, o instalador Anaconda do Fedora (e outros instaladores de distribuição Linux conhecidos) não pode redimensionar os volumes do BitLocker. Porém, é possível redimensionar volumes do BitLocker no Windows, portanto, é mais uma questão de documentação para informar os usuários que planejam a inicialização dupla que eles devem primeiro garantir que tenham espaço livre suficiente em seu sistema redimensionando quaisquer volumes criptografados.
A outra característica mais urgente é que a chave de criptografia do BitLocker seja deslacrada somente se a medição da cadeia de inicialização pelo TPM corresponder aos valores esperados em um TPM PCR.
Ao usar o shim e o GRUB na cadeia de inicialização, conforme usado pelo Fedora por padrão para configurações de inicialização dupla, os valores de medição estão errados e a chave de criptografia do BitLocker não pode ser deslacrada corretamente.
Os usuários que tentarem fazer dual boot com a versão atual do Fedora Linux serão levados para uma tela de recuperação do BitLocker ao tentar inicializar o Windows 10/11 com este método de criptografia de disco completo.
Esses desafios do Windows BitLocker são conhecidos há meses e originalmente um bug do bloqueador do Fedora 36 até serem desviados para o Fedora 37 devido aos obstáculos.
Qual seria a solução, se é que existe?
Entre os caminhos a serem seguidos, está a modificação do GRUB para definir o valor “boot next” da UEFI NVRAM, de modo que, em vez do carregamento em cadeia, definirá a próxima inicialização do sistema diretamente no carregador de inicialização do Windows.
No entanto, o GRUB upstream não está particularmente interessado nesse recurso, enquanto o systemd-boot já implementou suporte para ele. Ou há também a possibilidade de criar um utilitário de espaço do usuário para modificar a NVRAM do sistema para modificar a próxima configuração de inicialização para inicializar diretamente no carregador de inicialização do Windows.
Essas dores de cabeça do BitLocker estão sendo discutidas na lista de discussão do Fedora. Porém em última análise, é um problema mais amplo para as distribuições Linux ao lidar com volumes criptografados do BitLocker e outras distribuições que dependem do GRUB.
