Alternative support for native encryption via a systemd service

[csdvrx]

Native encryption is currently not supported.

PR#4 offers a C based solution, but it hasn't been mainlined yet

I'd like to suggest an alternative solution that could be immediately mainlined since it's a pure systemd based solution: it only requires starting the service : systemctl daemon-reload ; systemctl start --now zfs-askpassword@rpool-enc

The use of conditions means no password will be asked if the key is already available, so it should also be safe to add as a default

The lack of instance parameters (starting zfs-askpassword instead of the parametrized zfs-askpassword@rpool-enc) is managed via DefaultInstance=pool-enc which can be used to hardcode a default name (here pool/enc due to how systemd escaping works)

The ExecStart line can be modified to support other methods to provide the key, for example tpm2 based (unseal) or luks based (by specifying the location of the keyfile on the filesystem)

Currently, the solution depends on 2 services: [email protected] and zfs-remount.service due to my limited understanding of the systemd ordering sequence for sd-zfs.

However, the 2nd service is only present to have zfs mount mount the non-legacy dataset in their expected mointpoints on the filesystem as a separate step: if deemed desirable, the same result could be achieved via:

ExecStartPost=+/bin/sh -c 'zfs mount -a'

Ideally, this service would be generated by sd-zfs, to correctly fill the default DefaultInstance=pool-enc based on the bpool parameter, and automatically include the dependencies from systemd-ask-password in mkinitcpio.conf:

• FILES should contain /etc/systemd/system/sysroot.mount.wants/[email protected] /usr/lib/systemd/system/systemd-ask-password-console.service if rpool/enc is the natively encrypted bpool
• BINARIES should contain systemd-ask-password systemd-tty-ask-password-agent and anything else needed for other methods (ex: tpm2_unseal or luks binaries)

[ciphorg]

Really good ideas in here, but there are few caveats I'd like to add:

I believe the original maintainer of this library has completely abandoned this, and mkinitcpio needs another solution. I would also be hesitant run your version and sd-zfs's version on any machine with important data.

No implementation of systemd-generators

Your services combine many components into virtual bash scripts which do not provide error handling.

Generators are the preferred method of modifying systemd at during early-boot. They provide an organized method of generating any type of systemd units, and then properly expunging them upon initrd-switch-root.target. [systemd.generator]

Take a look at sd-zfs' generator, and then compare to dracut's zfs module. Dracuts module does what sd-zfs does but in a more robust fashion.

Create a mkinitcpio module from your files

Your mkinitcpio.conf explanation isn't clear here. It would be better to describe the tooling into a mkinitcpio.install file, which will install the required binaries, scripts, and systemd unit files into the initramfs image without cluttering the conf files.