O particionamento de uma imagem de disco virtual de um convidado Lubuntu KVM que instalei recentemente é assim:
# lsblk -f
NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
loop0 squashfs
0 100% /rofs
... SNIP ...
sr0 iso9660 Ubuntu 19.10 amd64 2019-10-17-12-53-34-00 0 100% /cdrom
vda
└─vda1 crypto_LUKS xxxx-yyyy-zzzz
Em outras palavras, possui uma única partição de sistema criptografada ( vda1) e nenhuma partição de inicialização. (NB. Inicializei em uma imagem ao vivo para examinar/redimensionar a partição criptografada e fiquei surpreso com a falta de partição de inicialização.)
Pergunta:como o sistema consegue inicializar (porque ele inicializa!) Apesar de não haver partição de inicialização?
Perguntas de acompanhamento para meu melhor entendimento:
- A inicialização funciona porque o KVM gerencia a descriptografia sozinho?
- Ou isso funcionaria também em um sistema host?
- Se também funcionasse em uma configuração autônoma, por que criamos a partição de inicialização (não criptografada), e não apenas a partição criptografada autônoma, como esta?
- Se é o KVM que gerencia a descriptografia, o que garante que o KVM tenha
cryptsetupinstalada a versão correta/compatível que foi usada para criar o dispositivo criptografado? E se a versão não corresponder? - Se é o KVM que gerencia a descriptografia, então presumo que no momento de instalar o Lubuntu com criptografia completa de disco, a instalação notou que ele estava rodando em uma VM e decidiu que criar uma única partição criptografada seria suficiente. É este o caso? E se sim, por que não perguntou se eu queria a configuração "normal", com a partição de boot?
Observação: na verdade, a interface gráfica para abrir o disco criptografado na inicialização é bastante espartana. É uma interface baseada em texto, onde eu tenhoum únicotente inserir a frase secreta para abrir a partição criptografada, sem nenhum feedback (os asteriscos não parecem mostrar pelo menos quantos caracteres eu digitei). Antes eu presumia que o motivo era que o Lubuntu é mais simples que o Ubuntu, mas agora suspeito (como escrito acima) que o próprio KVM gerencia a descriptografia.
Responder1
Existem várias possibilidades:
nenhuma partição de inicialização é necessária ao usar particionamento MBR/DOS, GRUB com suporte a disco criptografado e LUKS 1 (ou LUKS 2 com senha PBKDF2). Versões futuras do GRUB podem suportar totalmente o LUKS 2, mas ainda não chegou lá (nenhum suporte para argon2i ainda).
kernel/initramfs pode ser armazenado externamente e carregado diretamente pelo qemu/KVM, passando
-kernel -initrdas opções apropriadas para o qemu. Neste caso, o próprio qemu atua como o carregador de boot, portanto não há necessidade de uma partição de boot dentro da VM.A imagem do kernel pode existir em um deslocamento de dispositivo específico antes da primeira partição - não uma partição/sistema de arquivos/arquivo, mas gravada diretamente como dados brutos no dispositivo, e o gerenciador de inicialização sabe onde procurá-lo. Essa abordagem geralmente é vista apenas em dispositivos incorporados.
por que criamos a partição de inicialização (não criptografada), e não apenas a partição criptografada independente, como esta?
O problema é que o bootloader precisa ir para algum lugar, e assim, com o particionamento MBR/DOS, muito disso acontecia no espaço não particionado. Claro que isso pode funcionar... até que duas coisas diferentes tentem colocar seus dados no mesmo deslocamento e se sobrescreverem, de qualquer maneira.
Foi decidido que é melhor ter partições adequadas para estes. Portanto, com GPT você obtém uma partição EFI e/ou GRUB obtém uma partição bios_grub para sua imagem principal e assim por diante.
Idealmente, você pode olhar para a tabela de partições e saber como ela está configurada, e não coçar a cabeça e perguntar aqui como as coisas funcionam, porque está tudo escondido e escondido fora do particionamento em algum lugar.