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

[Tim Dittler]

Thank you for your feedback, Lennart. To be honest, the UX of the
operation has been a secondary concern for us so far. We're basically
exploring what is possible atm. Our current approach is to re-use the
initramfs which was used during boot before. This doesn't include
X11/wayland. While it would be great to make the suspension as smooth as
possible, I think there is also a place for people who *really* want a
whole encrypted disk during suspend and are okay to jump through a few
hoops for that.

Best,
Tim

On 09.10.19 19:26, Lennart Poettering wrote:
> On Mi, 09.10.19 12:20, Jonas Meurer (jonas at freesources.org) 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
>