initramfs: add support for mkinitcpio initramfs generator

[diabonas]

mkinitcpio is the default mkinitcpio used by Arch Linux. It can be extended through custom hooks, so provide one that installs all the necessary files for clevis luks unlock to function. The device to be unlocked is configured through the cryptdevice kernel command line option in the same way the built-in encrypt mkinitcpio hook works.

Resolves: #334

[richie-tt]

Hi, is there any possibility of further consideration of this Pull Request?

@sergio-correia @sarroutbi @oldium ?

[sarroutbi]

Sorry, but I don't have enough knowledge about mkinitcpio. It LGTM, but I would prefer @sergio-correia , @oldium to share their opinion

[oldium]

mkinitcpio is Arch-specific tool, something like Debian's mkinitramfs. According to Arch documentation, it supports old-fashioned scripted unlocking (via encrypt module), but also supports systemd startup, like Dracut with systemd (but I have not seen it running, so I just guess it is similar), for more standardized cryptsetup loading.

The current mkinitramfs/Dracut way to unlock the devices is to hook into the password-providing paths and provide a correct password and let the reponsible code to pass the correct options to cryptsetup (like --allow-discards for SSDs).

This implementation is limited in the way that it specifically requires running before encrypt module (which does the old-fashioned unlocking without systemd), parses the encrypt's cryptdevice kernel cmdline parameter, and unlocks the device by a call to clevis unlock. No options are passed to cryptsetup.

I like the way how we currently hook into the password workflow just to provide the password and let the responsible scripts to unlock the device and provide correct cryptsetup options. We are able to hook into the cryptsetup askpass, plymouth ask-for-password, systemd-ask-password, but also to a key-file reading paths (which I added in this commit - not yet merged). We are rather flexible in this.

So it depends on how to proceed. I think the most future proof is to pass the unlocking to the system scripts specifically written for unlocking, and hook into the password-providing path only. For me the best of all worlds is systemd, because it allows adding TPM1 unlocking (it requires Trousers daemon running), all others require manually starting the daemon and terminating it. But also non-systemd paths are doable, it just takes more time...