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

[Dimitri John Ledkov]

On Thu, 10 Oct 2019 at 16:49, Mantas Mikulėnas <grawity at gmail.com> wrote:
>
> 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?
>

Well, one can do what Mac OS X used to do. Take a screenshot, apply
blur, use as a background in a graphical plymouth to type unlock
password and slowly fade in as things are unfrozen.

Most desktop systems, already might include graphical plymouth already
(and like framebuffer / dri modules needed for it, among with
cryptsetup tooling but maybe not TPM one). Such that it should be
possible to "just use the initrd" one uses for boot anyway.

>
> 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.

-- 
Regards,

Dimitri.