Confira !!
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 conveniente de inicialização dupla para aqueles que desejam manter o Windows e o Linux nos mesmos sistemas.
Os engenheiros do Fedora / Red Hat estão tocando os sinos de alarme sobre a inicialização dupla do Windows e do Linux, tornando-se mais desafiadores para suportar. Em particular, o BitLocker do Windows para criptografia de disco completo em que a chave de criptografia é lacrada usando o hardware TPM.
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. Mas é 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.
O Windows 11 aumentou a promoção da criptografia de disco BitLocker é bom para a segurança, mas apresenta mais desafios para coexistir bem com distribuições Linux no mesmo hardware.
A outra maneira 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 a inicialização dupla 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 desafiadores. 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. Mas 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, mas, 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.
Até a próxima !!
Nenhum comentário:
Postar um comentário