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 (jo...@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 > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
