[Feature] Support System Filesystem Encryption in the New Installer

[zont0x]

We hope that the new‑version installer can add support for system filesystem encryption. Thank you very much!

[Anduin2017]

Planned. But this is very hard... Since currently the Ubuntu's grub doesn't provide Argon2ID plugin.

[zont0x]

Appreciate your reply. It makes sense that missing the Argon2ID GRUB plugin brings big obstacles. No rush at all, I’m looking forward to future progress on this feature.

[Anduin2017]

Ubuntu seems separated the initrd and kernel out of btrfs volume.

[zont0x]

Good to know! This change should help implement system encryption without requiring GRUB Argon2ID plugin. Thanks for your work.

[siyamsec-lab]

I agree that filesystem encryption would be a great addition to the new installer. I understand that the lack of Argon2id support in Ubuntu’s GRUB makes this technically difficult, but hopefully there will be a practical solution that can provide secure LUKS2-based system encryption without requiring GRUB to directly handle Argon2id. It would be especially useful if the installer could eventually provide an optional “Encrypt system” option during installation.

…

On Mon, 24 Aug 2026 at 16:54, Anduin Xue ***@***.***> wrote: Ubuntu seems separated the initrd and kernel out of btrfs volume. — Reply to this email directly, view it on GitHub <#417?email_source=notifications&email_token=B4VDWAAQPGWPYQKV2GYB4435LQNH5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBRGMZTSMRWUZZGKYLTN5XKU43VMJZWG4TJMJSWJJLFOZSW45FMMZXW65DFOJPWG3DJMNVQ#discussioncomment-18133926>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B4VDWAG3NA3KU4QYWB3DSCL5LQNH5AVCNFSNUABIKJSXA33TNF2G64TZHM3DQMZWGA2TANJVHNCGS43DOVZXG2LPNY5TCMBWG4YTGMZRUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/B4VDWABLAE4MHA5TM3X5VZL5LQNH5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBRGMZTSMRWUZZGKYLTN5XKU43VMJZWG4TJMJSWJJLFOZSW45FKMZXW65DFOJPWS33T> and Android <https://github.com/notifications/mobile/android/B4VDWAHHTIX2FHHTNSU5H2L5LQNH5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBRGMZTSMRWUZZGKYLTN5XKU43VMJZWG4TJMJSWJJLFOZSW45FOMZXW65DFOJPWC3TEOJXWSZA>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[Anduin2017]

We have been evaluating several ways to combine Btrfs snapshots, full-disk encryption, Secure Boot, and atomic kernel rollback in AnduinOS.

The core problem is simple:

• We want /boot, the kernel, initramfs, modules, package state, and userspace to live inside the same encrypted Btrfs snapshot. Or there will be issue when rolling back the root fs without rolling back the kernel.
• But GRUB runs before the encrypted root is unlocked.
• Ubuntu avoids this by keeping /boot unencrypted, so it never has to solve atomic rollback between /boot and the root filesystem. And Ubuntu doesn't provide the feature to rollback to a snapshot.

The main options we discussed are:

Branch A — LUKS2 data + detached LUKS1 header for GRUB

Keep the real root as modern LUKS2+Btrfs, but place a small detached LUKS1 compatibility header on the ESP. Ubuntu’s signed GRUB can use that old-format header to unlock the same encrypted data area.

Pros

• Uses Ubuntu’s existing signed shim and GRUB.
• Secure Boot stays enabled.
• No MOK enrollment.
• No extra preboot Linux kernel.
• Real kernel/initramfs stay encrypted inside Btrfs and roll back atomically.
• Only one visible password prompt.
• We already have substantial VM proof-of-concept coverage.

Cons

• Very complex key/header lifecycle.
• Password/recovery-key changes touch both LUKS metadata worlds.
• ESP must occasionally become writable.
• Human password is constrained by GRUB/LUKS1 PBKDF limitations rather than a clean modern LUKS2-only design.
• Depends on GRUB functionality Ubuntu does not really consider a supported FDE architecture.
• Does not resist an offline evil-maid attacker modifying ESP boot policy.

Branch C — Minimal Linux firmware loader + kexec

Keep a fixed signed Ubuntu kernel/initramfs on the ESP. It boots only to ask for the disk password, unlock LUKS2 with normal Linux cryptsetup, mounts encrypted Btrfs, then kexecs the real kernel/initramfs stored inside the selected snapshot.

Pros

• Clean, standard LUKS2 with Argon2id.
• No detached compatibility header.
• ESP can be almost immutable and normally not even mounted.
• Real kernel, initramfs, command line, modules and userspace all roll back together.
• No MOK or custom Secure Boot certificate.
• Future TPM/FIDO2 integration is much easier because the unlocker is Linux userspace.

Cons

• Every cold boot starts two Linux kernels.
• Requires kexec_file_load() and careful Secure Boot/lockdown testing.
• Needs a machine reopen key inside the encrypted real initramfs so the second kernel can reopen LUKS without asking twice.
• Needs a small snapshot-local boot manifest so the loader knows the correct kernel, initrd and command line.
• More hardware qualification work because kexec does not perform a full firmware reinitialization.
• The ESP-side initramfs is not fully authenticated by Ubuntu’s classic Secure Boot chain, so this also does not resist evil-maid attacks.

Branch B — Machine-local MOK, custom GRUB

Generate a per-machine signing key, enroll it through MokManager, then use a custom self-contained GRUB that directly understands the required LUKS2/Btrfs stack and only boots trusted root-owned artifacts.

Pros

• Clean single-stage boot.
• No detached LUKS1 header.
• Can enforce a much stronger boot policy than Ubuntu’s stock GRUB.
• Kernel/initramfs remain inside encrypted Btrfs snapshots.
• No Microsoft signing contract required.

Cons

• Every user must perform a MOK enrollment step.
• Key loss/recovery/update UX becomes part of the OS installer.
• Considerably more Secure Boot policy code to maintain.
• Still requires us to maintain our own GRUB build.

Branch M — Microsoft-signed AnduinOS shim

This is probably the long-term “real distribution” solution.

We obtain an EV code-signing certificate to enter Microsoft’s UEFI signing process, build an AnduinOS shim containing our own Boot CA, pass shim-review, and have Microsoft sign that shim. After that, the AnduinOS trust chain can validate our own GRUB/kernel/UKI artifacts.

Conceptually:

UEFI
  -> Microsoft-signed AnduinOS shim
  -> AnduinOS-signed GRUB
  -> LUKS2 + Btrfs
  -> AnduinOS-signed kernel/UKI

Pros

• No MOK enrollment for ordinary users.
• No detached LUKS1 compatibility header.
• No kexec double boot.
• We control GRUB and can include exactly the crypto/Btrfs modules we need.
• Real boot artifacts remain encrypted and snapshot-local.
• Can eventually provide a proper verified-boot chain rather than merely “Secure Boot is enabled.”
• This is the closest thing to a final distribution-owned architecture.

Cons

• Administrative and security-review process is much heavier.
• Requires reproducible builds, SBAT/revocation planning, signing infrastructure and protected private keys.
• Microsoft signs the shim, not arbitrary future binaries for us; we then become responsible for our downstream trust chain.
• We must maintain our own GRUB security patches and boot policy.
• This is a distribution security program, not merely an installer feature.

Why Ubuntu does not have this problem

Ubuntu mostly sidesteps it.

Its classic encrypted installation looks roughly like:

ESP          unencrypted
/boot ext4   unencrypted
LUKS2
  -> LVM
     -> root

GRUB reads the plaintext kernel and initramfs from /boot. The initramfs then runs cryptsetup, unlocks LUKS2, activates LVM and mounts the real root.

That is simple and mature, but Ubuntu does not promise that rolling back a Btrfs root snapshot also atomically rolls back the matching kernel, initramfs, DKMS state and boot configuration.

AnduinOS wants a stronger invariant:

A system snapshot must contain the entire bootable operating-system generation, including the kernel.

That requirement is what turns /boot placement into a real architecture problem.

At the moment, Branch A is the most heavily proven mechanism, Branch C is the cleanest certificate-free LUKS2 design, and Branch M is probably the long-term distribution-grade end state.

[Anduin2017]

Branch D — Snapshot-bound signed UKIs on the ESP

Another possible design is to stop requiring the kernel itself to live inside the encrypted Btrfs snapshot.

Instead, each bootable system deployment gets a matching signed UKI on the ESP:

ESP
├── anduinos-101.efi
└── anduinos-102.efi

LUKS2 + Btrfs
├── deployment 101
└── deployment 102

Each UKI contains the matching kernel, initramfs and kernel command line. Linux then unlocks the real LUKS2 root using normal cryptsetup, so GRUB does not need LUKS2/Argon2 support.

Pros

• Native LUKS2 + Argon2id.
• Single-stage boot, no kexec.
• Kernel + initramfs + cmdline can be signed together.
• Stronger resistance to evil-maid tampering.
• Fits modern UKI/systemd-boot tooling well.

Cons

• ESP and Btrfs are separate transaction domains, so rollback is not automatically atomic.
• Requires a deployment manager to bind each UKI to the correct Btrfs snapshot.
• Needs crash-safe activation, fallback and garbage collection.
• Per-machine UKI signing is difficult without MOK or our own trusted shim infrastructure.
• Historical UKIs consume ESP space.

So Branch D trades bootloader crypto complexity for deployment-management complexity.

[Anduin2017]

Updated comparison

Branch	Main idea	Advantages	Main problems
A	LUKS2 data + detached LUKS1 header	Already heavily tested, single-stage boot, encrypted /boot, no MOK	Dual-header lifecycle, PBKDF2 compatibility path, complex recovery/update logic
B	Per-machine MOK + custom GRUB	Clean LUKS2 design, strong boot policy, single-stage boot	Every user must enroll MOK, more complicated UX
C	Minimal Linux unlocker + kexec	Pure LUKS2/Argon2id, almost immutable ESP, no custom signing infrastructure	Two kernel boots, kexec/hardware compatibility, unsigned Stage-1 initrd
D	Signed UKIs on ESP bound to Btrfs deployments	Single-stage boot, modern LUKS2, signed kernel+initrd+cmdline, no GRUB crypto	Requires an OSTree-like deployment transaction layer; UKI signing/trust must be solved
M	Microsoft-signed AnduinOS shim	Full distribution-owned Secure Boot trust, no user MOK, can sign our own GRUB/kernel/UKI	Heavy compliance, shim-review, SBAT, signing infrastructure and long-term security maintenance

The important realization is that these branches solve slightly different problems.

The important realization is that these branches solve slightly different problems.

Branch M is mainly a trust architecture: who does Secure Boot trust?

Branch D is mainly a deployment architecture: how do we bind an external boot artifact to a particular Btrfs system generation?

So the likely long-term comparison is not really D vs M, but:

M + encrypted root-owned /boot

versus:

M + D

The first keeps kernel and userspace inside the same Btrfs transaction domain.

The second keeps the bootloader simple and lets Linux handle modern encryption, but requires us to build a real deployment manager to keep ESP UKIs and Btrfs generations consistent.

Branch D is therefore very promising, but it does not make the atomicity problem disappear — it moves that problem from GRUB/LUKS into deployment management.