[systemd-devel] Context for "exitrd"

Mantas Mikulėnas grawity at gmail.com
Fri Dec 31 20:21:22 UTC 2021


On Fri, 31 Dec 2021 at 20:46, Albert Brox <albert at exypno.tech> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20211231/f4657702/attachment.htm>


More information about the systemd-devel mailing list