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

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mi, 09.10.19 12:20, Jonas Meurer (jonas@xxxxxxxxxxxxxxx) wrote:

> Hi systemd devs,
>
> We[1] are working on bringing luksSuspend for LUKS devices before system
> suspend to Debian. The basic idea is to remove the encryption keys of
> encrypted devices from RAM before suspending the system.
>
> While working on it, we figured out that systemd probably is the best
> place to implement this. Would you be willed to accept related patches
> into systemd? We're still early in the design process, but probably the
> relevant parts will be:
>
> * create a minimalist ramfs chroot environment with all required
>   components to unlock the suspended LUKS encrypted root filesystems.
> * freeze most processes before suspending the system to prevent timeouts
>   when a process asks for resources from suspended block devices before
>   the block device gets luksResumed.
> * luksSuspend all active LUKS devices before suspend in sleep/sleep.c.
> * luksResume all formerly active LUKS devices after resume.
> * unfreeze/continue all frozen processes.
>
> Lennart's talk[2] about systemd-homed mentions luksSuspend support for
> system suspend, but it's limited to home directories. The whole ramfs
> foo wouldn't be necessary to do that. So a direct question: would you
> still be ok with support for luksSuspending the encrypted root
> filesystem in systemd?
>
> Before spending days of work on implementing this in systemd only to get
> the patches rejected in the end, we thought it would be better to ask
> beforehands ;)
>
> So far, we have a working systemd-independent proof of concept: a
> systemd-suspend.service override invokes a shell script[3] that takes
> precautions, runs luksSuspend, then suspends the system and runs
> luksResume after the system has been resumed.
>
> We're looking forward to your comments :)

The thing is, this is far from easy to implement, to the point I don't
think it's viable in the long run at all. I mean, in order to be able
to unlock the root disk after suspend you need the full input and
display stack to be up, i.e. wayland/x11/gnome in the general
case. And that's an awful lot to place in a ramdisk. You will end up
having another copy of the OS as a whole in there in the end...

systemd-homed maintains only the home directory via LUKS encryption,
and leaves the OS itself unencrypted (under the assumption it's
protected differently, for example via verity – if immutable —  or via
encryption bound to the TPM), and uses the passphrase only for
home. THis means the whole UI stack to prompt the user is around
without problems, and the problem gets much much easier.

So what's your story on the UI stack? Do you intend to actually copy
the full UI stack into the ramdisk? If not, what do you intend to do
instead?

Lennart

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