☰

Eine einzelne verschlüsselte Systempartition ohne Bootpartition – wie ist das möglich?

tag-icon • tag-icon boot partition virtual-machine kvm
Eine einzelne verschlüsselte Systempartition ohne Bootpartition – wie ist das möglich?

Die Partitionierung eines virtuellen Disk-Images eines Lubuntu KVM-Gastes, das ich kürzlich installiert habe, sieht folgendermaßen aus:

# 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

Mit anderen Worten, es hat eine einzige verschlüsselte Systempartition ( vda1) und keine Bootpartition. (NB. Ich habe in ein Live-Image gebootet, um die verschlüsselte Partition zu untersuchen/ihre Größe zu ändern, und war überrascht, dass es keine Bootpartition gab.)

Frage:wie schafft es das System, hochzufahren (denn es fährt hoch!), obwohl keine Boot-Partition vorhanden ist?

Noch eine Nachfrage zu meinem besseren Verständnis:

  • Funktioniert das Booten, weil KVM die Entschlüsselung selbst durchführt?
  • Oder würde dies auch auf einem Hostsystem funktionieren?
  • Wenn es auch in einer eigenständigen Konfiguration funktionieren würde, warum erstellen wir dann überhaupt die (unverschlüsselte) Boot-Partition und nicht nur die eigenständige verschlüsselte Partition wie diese?
  • Wenn KVM die Entschlüsselung verwaltet, wie wird dann sichergestellt, dass KVM die richtige/kompatible Version cryptsetupinstalliert hat, die zum Erstellen des verschlüsselten Geräts verwendet wurde? Was passiert, wenn die Version nicht übereinstimmt?
  • Wenn KVM die Entschlüsselung verwaltet, gehe ich davon aus, dass install bei der Installation von Lubuntu mit vollständiger Festplattenverschlüsselung bemerkt hat, dass es in einer VM ausgeführt wird, und entschieden hat, dass das Erstellen einer einzelnen verschlüsselten Partition ausreichen würde. Ist das der Fall? Und wenn ja, warum wurde ich nicht gefragt, ob ich das „normale“ Setup mit der Bootpartition möchte?

Bemerkung: Tatsächlich ist die GUI zum Öffnen der verschlüsselten Festplatte beim Booten ziemlich spartanisch. Es ist eine textbasierte GUI, bei der ichein einzelnesVersuch, die Passphrase einzugeben, um die verschlüsselte Partition zu öffnen, ohne jegliche Rückmeldung (die Sternchen scheinen nicht anzuzeigen, wie viele Zeichen ich eingegeben habe). Vorher ging ich davon aus, dass der Grund darin liegt, dass Lubuntu einfacher ist als Ubuntu, aber jetzt vermute ich (wie oben geschrieben), dass KVM die Entschlüsselung selbst verwaltet.

Antwort1

Es gibt mehrere Möglichkeiten:

  • Bei Verwendung von MBR/DOS-Partitionierung, GRUB mit Cryptodisk-Unterstützung und LUKS 1 (oder LUKS 2 mit PBKDF2-Passphrase) ist keine Bootpartition erforderlich. Zukünftige Versionen von GRUB könnten LUKS 2 vollständig unterstützen, aber meines Wissens ist es noch nicht so weit (noch keine Argon2i-Unterstützung).

  • Kernel/Initramfs können extern gespeichert und direkt von Qemu/KVM geladen werden, indem entsprechende -kernel -initrdOptionen an Qemu übergeben werden. In diesem Fall fungiert Qemu selbst als Bootloader, sodass auch innerhalb der VM keine Bootpartition erforderlich ist.

  • Das Kernel-Image kann an einem bestimmten Geräte-Offset vor der ersten Partition vorhanden sein – nicht als Partition/Dateisystem/Datei, sondern direkt als Rohdaten auf das Gerät geschrieben, und der Bootloader weiß, wo er danach suchen muss. Dieser Ansatz wird normalerweise nur bei eingebetteten Geräten verwendet.

warum erstellen wir überhaupt die (unverschlüsselte) Boot-Partition und nicht einfach die eigenständige verschlüsselte Partition wie diese?

Das Problem ist, dass der Bootloader schließlich irgendwo hin muss, und daher passierte bei der MBR/DOS-Partitionierung viel davon im unpartitionierten Bereich. Sicher, das kann funktionieren ... jedenfalls nicht, bis zwei verschiedene Dinge versuchen, ihre Daten am gleichen Offset zu platzieren und sich gegenseitig überschreiben.

Es wurde entschieden, dass es besser ist, dafür richtige Partitionen zu haben. Mit GPT erhalten Sie also eine EFI-Partition und/oder GRUB erhält eine bios_grub-Partition für sein Kernabbild und so weiter.

Im Idealfall können Sie dann einen Blick auf die Partitionstabelle werfen und wissen mehr oder weniger, wie sie eingerichtet ist, und müssen sich nicht am Kopf kratzen und fragen, wie die Dinge überhaupt funktionieren, weil alles irgendwo außerhalb der Partitionierung verstaut und verborgen ist.

verwandte Informationen