Re: RFC: luksSuspend support in sleep/sleep.c

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mo, 14.10.19 16:27, Jonas Meurer (jonas@xxxxxxxxxxxxxxx) wrote:

> Yeah, something like that was my hope as well: use plymouth and
> framebuffer or something alike for spawning the passphrase prompt. But
> I'm not sure yet how to ensure that we change to the passphrase prompt
> (or overlay the graphical desktop environment).
>
> Another idea that came into my mind: spawn the passphrase prompt
> *before* system suspend, just like it's apparently done with the
> screenlock right now.
>
> The passphrase prompt could write to a fifo pipe or talk to a small
> daemon that waits for the luks passphrase(s) to be entered.

Paging doesn't allow that really. It's always ugly. You'd have to have
your own UI stack in the initrd, i.e. basically have an alternative
root disk, that possesses the screen exclusively as long as the system
is up but not unlocked yet.

So most likely a comprehensive approch would be:

in systemd-suspend.service pass control to a binary in the initrd that
runs in its one fs namespace with only tmpfs and api vfs visible,
which includes plymouth and so on. It then switches to a new VT, does
plymouth there, then suspends, on coming back lets plymouth ask its
question and then unlocks the disk. And maybe even uses the cgroup
freezer to freeze all processes on the host (i.e. everything except
the stuff run from the initrd) before suspend, and thaw it only after
the password has been entered again, so that the whole OS remains
frozen and doesn't partially get woken up but hangs on the root disk,
because typing in the pw might take a loooong time...

But even that is very ugly for various reasons. For example
CLOCK_MONOTONIC will not be paused while the host remains frozen. Thus
watchdog events will be missed (actual system suspend pauses
CLOCK_MONOTONIC, which makes this safe for it), and then your system
is hosed. Moreover, your initrd main process will be a child of a
frozen process (as PID 1 is from the host), and this means you have to
be very very careful with what you do, since you then cannot rely on
some of the most basic functions of the OS. for example, PID 1 reaps
processes which get reparented to it normally. Thus in your initrd you
should be very careful never to have processes die while they have
children as they will collect as unreaped children of PID 1
then... One can ignore issues like that, but they are frickin ugly....

> >> They might not be 100% available from just memory. What happens
> >> if the DE needs to load assets (fonts, .ui files) for the
> >> passphrase prompt from disk? (Actually, do any GPU drivers need
> >> to load firmware from /lib on resume?)
> >>
> >
> > In Ubuntu, casper component, we work around it by reading the files to
> > ensure they are in the fscache, and then if one force unmounts the
> > filesystem underneath them (cdrom eject) plymouth can still "read"
> > fonts and display late boot messages. So there are ways of doing this.
>
> Again, the simplest solution would be to spawn the passphrase prompt
> *before* suspend, to ensure that all required components are already in
> memory. Or do you see caveats?

Programs are memory mapped on Linux, i.e. nominally on disk, only the
bits paged in as they are used, as they are executed. Similar, data
files are typically memory mapped too. This means that preparing
anything in advance is not that easy, you have to lock it into RAM
too. Which you can do, but doesn't really scale, since our dep trees
are large and fonts/media files in particular so.

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel