On Fri, 31 Dec 2021 at 20:46, Albert Brox <albert@xxxxxxxxxxx> wrote:
Hi all,
I'm interested in working on this item from the TODO file:
* add concept for "exitrd" as inverse of "initrd", that we can
transition to at
shutdown, and has similar security semantics. This should then take
the place
of dracut's shutdown logic. Should probably support sysexts too. Care
needs
to be taken that the resulting logic ends up in RAM, i.e. is copied
out of
on-disk storage.
I'm wondering if anyone can elaborate/give context for this.
Specifically, what is the motivation for replacing the dracut shutdown
logic with exitrd? It seems like dracut already handles shutdown
processes within a ramdisk/fs. And as I understand, initrd is not part
of systemd (merely interfaced with), so why are we bringing this
"exitrd" under the umbrella of systemd?
If I remember right, this whole concept of having init pivot_root back into /run to let root be unmounted (aka "shutdown initramfs") *was* originally introduced by systemd in the first place.
(Init has to be involved because it's the one process that can't be killed to relinquish its open handles on /, it has to be nicely asked to do so. Sysvinit didn't have such a thing as far as I remember, but systemd was changed in 2011 to optionally pivot_root to /run/initramfs and execute the 'shutdown' binary found there instead of powering off. That's what allows dracut shutdown logic to be run.)
But while the initramfs is a pre-built image that can be distributed and signed, the shutdown logic is not; it's instead unpacked or even generated on the fly by an ordinary .service that runs before every shutdown. At least on Arch it literally runs mkinitcpio; not sure about dracut.
So I'm assuming that the whole idea of "exitrd" is just to make the same "initramfs update" process generate both halves as static cpio images at the same time, so that it would become systemd's job to simply unpack it to /run (and maybe validate a signature or two).
Mantas Mikulėnas
