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 (jo...@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? > [...] 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. Let me stress this aspect a bit more: at the moment, full diskt encryption is the way to go if you want encryption at rest on your laptop. I applaud your efforts regarding systemd-homed, but they probably will not be the default setup anytime soon. Especially not if you talk about immutable or TPM-bound-encrypted rootfs. And *unencrypted* rootfs clearly shouldn't be the way to go. Think about all the sensitive stuff in /etc, /var/lib and even unencrypted swap devices. But the main poinf of your feedback probably is that we need a clear vision how to technically solve the UI issue before you consider this a valid candiate for systemd inclusion, right? By the way, we discovered a possible dead lock between luksSuspend and the final sync() in the Linux Kernel system suspend implementation that you most likely will discover with your luksSuspend systemd-homed as well. We're currently working on getting a Kernel patch accepted that adds a run-time switch to disable the sync() in the Kernel system suspend implementation. Cheers jonas
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
