Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c
Hi again, Dimitri John Ledkov: > On Thu, 10 Oct 2019 at 16:49, Mantas Mikulėnas wrote: >> On Thu, Oct 10, 2019 at 6:23 PM Jonas Meurer wrote: >>> 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? >> > > 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. Yeah, something like that was my hope as well: use plymouth and framebuffer or something alike for spawning the passphrase prompt. But I'm not sure yet how to ensure that we change to the passphrase prompt (or overlay the graphical desktop environment). Another idea that came into my mind: spawn the passphrase prompt *before* system suspend, just like it's apparently done with the screenlock right now. The passphrase prompt could write to a fifo pipe or talk to a small daemon that waits for the luks passphrase(s) to be enter
Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c
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
[systemd-devel] RFC: luksSuspend support in sleep/sleep.c
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 :) Kind regards, Tim and Jonas [1] We are Tim and Jonas. For six months, we're funded part-time by the PrototypeFund to work on luksSuspend before system suspend in Debian. [3] https://media.ccc.de/v/ASG2019-164-reinventing-home-directories [2] https://salsa.debian.org/mejo/cryptsetup-suspend/blob/master/debian/cryptroot-suspend/cryptroot-suspend.c and https://salsa.debian.org/mejo/cryptsetup-suspend/blob/master/debian/cryptroot-suspend/cryptroot-suspend-wrapper signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
