[systemd-devel] RFC: luksSuspend support in sleep/sleep.c

[Mantas Mikulėnas]

On Thu, Oct 10, 2019 at 6:23 PM Jonas Meurer <jonas at freesources.org> wrote:

> Hi Lennart, hi Tim,
>
> thanks a lot for your feedback, Lennart. It's much appreciated!
>
> Tim Dittler:
> > On 09.10.19 19:26, Lennart Poettering wrote:
> >> On Mi, 09.10.19 12:20, Jonas Meurer (jonas at freesources.org) wrote:
> >>> 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:
> >>>
> >>> [...]
> >>>
> >>> 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 ;)
> >>
> >> 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?
>
> As Tim already wrote, the UI stack was not our focus so far. But I
> agree, that it's a valid concern. My silent hope was to find a solution
> for a simple passwort prompt that can be overlayed over whatever
> graphical stack is running on the system. But we haven't looked into it
> yet, so it might well be impossible to do something like this.
>
> But since the graphical interface is running already, I doubt that we
> would have to copy the whole stack into the ramfs. We certainly need to
> take care of all *new* dependencies that a password prompt application
> pulls in, but the wayland/x11/gnome basics should just be there, as they
> have been in use just before the suspend started, no?
>

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?)

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20191010/f8fc839f/attachment.html>