☰

ブート パーティションのない単一の暗号化されたシステム パーティション - どうしてそれが可能なのでしょうか?

tag-icon • tag-icon boot partition virtual-machine kvm
ブート パーティションのない単一の暗号化されたシステム パーティション - どうしてそれが可能なのでしょうか?

最近インストールした Lubuntu KVM ゲストの仮想ディスク イメージのパーティションは次のようになります。

# 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

つまり、暗号化されたシステム パーティション ( vda1) が 1 つだけあり、ブート パーティションはありません。(注: 暗号化されたパーティションを検査/サイズ変更するためにライブ イメージを起動しましたが、ブート パーティションがないことに驚きました。)

質問:ブート パーティションがないにもかかわらず、システムはどのようにして起動できるのでしょうか (実際に起動します)?

理解を深めるための追加の質問:

  • KVM が復号化自体を管理するため、ブートは機能しますか?
  • それとも、これはホストシステムでも機能しますか?
  • スタンドアロン セットアップでも機能する場合、なぜこのようにスタンドアロンの暗号化パーティションだけでなく、(暗号化されていない) ブート パーティションを作成するのでしょうか?
  • 復号化を管理するのが KVM である場合、暗号化されたデバイスの作成に使用された正しい/互換性のあるバージョンが KVM にインストールされていることをどうやって確認するのでしょうcryptsetupか? バージョンが一致しない場合はどうなりますか?
  • 復号化を管理するのが KVM である場合、フルディスク暗号化を使用して Lubuntu をインストールしたときに、インストールは VM で実行されていることに気づき、暗号化されたパーティションを 1 つ作成するだけで十分であると判断したと考えられます。これは事実でしょうか。もしそうであれば、ブート パーティションを含む「通常の」セットアップが必要かどうかを尋ねなかったのはなぜでしょうか。

注意: 起動時に暗号化されたディスクを開くためのGUIは、実はかなり簡素です。これはテキストベースのGUIで、1つの暗号化されたパーティションを開くためにパスフレーズを入力しようとしましたが、フィードバックはまったくありませんでした (アスタリスクは、少なくとも入力した文字数を表示していないようです)。以前は、Lubuntu が Ubuntu よりもシンプルであることが理由だと考えていましたが、今では (上記のように) KVM が復号化自体を管理しているのではないかと疑っています。

答え1

いくつかの可能性があります:

  • MBR/DOS パーティション、暗号ディスクサポート付きの GRUB、および LUKS 1 (または PBKDF2 パスフレーズ付きの LUKS 2) を使用する場合、ブートパーティションは必要ありません。GRUB の将来のバージョンでは LUKS 2 を完全にサポートする可能性がありますが、私の知る限り、まだそこまでには至っていません (現時点ではargon2iはサポートされていません）。

  • kernel/initramfs は外部に保存され、適切な-kernel -initrdオプションを qemu に渡すことで qemu/KVM によって直接ロードされることがあります。この場合、qemu 自体がブートローダーとして機能するため、VM 内にブートパーティションも必要ありません。

  • カーネル イメージは、最初のパーティションの前の特定のデバイス オフセットに存在する場合があります。これは、パーティション / ファイルシステム / ファイルではなく、デバイスに生データとして直接書き込まれ、ブートローダはそれを検索する場所を認識します。このアプローチは通常、組み込みデバイスでのみ使用されます。

なぜこのようにスタンドアロンの暗号化パーティションではなく、(暗号化されていない) ブート パーティションを作成するのでしょうか?

問題は、ブートローダは結局どこかに置かなければならないということであり、MBR/DOS パーティションではその多くがパーティション化されていない領域で実行されることになります。確かに、それは機能するかもしれません... いずれにしても、2 つの異なるものが同じオフセットにデータを配置して、お互いを上書きしようとするまでは。

これらには適切なパーティションを用意した方がよいと判断されました。そのため、GPT では EFI パーティションが取得され、GRUB ではコア イメージ用の bios_grub パーティションが取得されるなどとなります。

理想的には、パーティション テーブルを見て、それがどのように設定されているかを知ることができ、すべてがパーティションの外側のどこかに隠れているため、頭を悩ませて、ここで物事がどのように機能するのかを尋ねる必要がなくなります。

関連情報