Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c
On Tue, Nov 5, 2019 at 8:33 AM Chris Murphy wrote: > > On Fri, Nov 1, 2019 at 2:31 PM Matthew Garrett wrote: > > > > The initrd already contains a UI stack in order to permit disk unlock > > at boot time, so this really doesn't seem like a problem? > > It's a very small and limited UI stack. At least the GNOME developers > I've discussed it with, this environment has all kinds of a11y, i18n, > and keymapping problems. To solve it means either baking a significant > portion of the GNOME stack into the initramfs, or some kind of magic > because the resources don't exist to create a minimized GNOME stack > that could achieve this. And so far the effort has been to try and > make the initramfs smaller, and more generic. I agree that the Plymouth UI stack isn't ideal for various reasons, but it's the UI stack that's used for unlocking the drive during boot so reusing it doesn't make things any worse than they already are. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c
On Fri, Nov 1, 2019 at 2:31 PM Matthew Garrett wrote: > > The initrd already contains a UI stack in order to permit disk unlock > at boot time, so this really doesn't seem like a problem? It's a very small and limited UI stack. At least the GNOME developers I've discussed it with, this environment has all kinds of a11y, i18n, and keymapping problems. To solve it means either baking a significant portion of the GNOME stack into the initramfs, or some kind of magic because the resources don't exist to create a minimized GNOME stack that could achieve this. And so far the effort has been to try and make the initramfs smaller, and more generic. I have no idea how either Apple or Microsoft solve this problem. -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c
On Thu, Oct 31, 2019 at 4:55 PM Lennart Poettering wrote: > Hmm, so far this all just worked for me, I didn't run into any trouble > with suspending just $HOME? What about /var and /home sharing the same volume? I'm pretty sure the default layout for Fedora Silverblue is a separate var volume, mounted at /var, with /var/home bind mounted to /home. -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c
On Thu, Oct 31, 2019 at 5:06 PM Lennart Poettering wrote: > Paging doesn't allow that really. It's always ugly. You'd have to have > your own UI stack in the initrd, i.e. basically have an alternative > root disk, that possesses the screen exclusively as long as the system > is up but not unlocked yet. The initrd already contains a UI stack in order to permit disk unlock at boot time, so this really doesn't seem like a problem? Switch VTs before suspend, suspend the LUKS devices so all access blocks and the keys are dropped, suspend, resume, run the unlock codepath from initramfs again, switch VTs back, we're good? Things are a little more complicated if you want to use the disk unlock phrase to also trigger desktop unlock, but everything else seems reasonably straightforward - processes will sit in D state until unlocked, but time will continue as expected. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c
On Mo, 14.10.19 16:27, Jonas Meurer (jo...@freesources.org) wrote: > 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 entered. Paging doesn't allow that really. It's always ugly. You'd have to have your own UI stack in the initrd, i.e. basically have an alternative root disk, that possesses the screen exclusively as long as the system is up but not unlocked yet. So most likely a comprehensive approch would be: in systemd-suspend.service pass control to a binary in the initrd that runs in its one fs namespace with only tmpfs and api vfs visible, which includes plymouth and so on. It then switches to a new VT, does plymouth there, then suspends, on coming back lets plymouth ask its question and then unlocks the disk. And maybe even uses the cgroup freezer to freeze all processes on the host (i.e. everything except the stuff run from the initrd) before suspend, and thaw it only after the password has been entered again, so that the whole OS remains frozen and doesn't partially get woken up but hangs on the root disk, because typing in the pw might take a lng time... But even that is very ugly for various reasons. For example CLOCK_MONOTONIC will not be paused while the host remains frozen. Thus watchdog events will be missed (actual system suspend pauses CLOCK_MONOTONIC, which makes this safe for it), and then your system is hosed. Moreover, your initrd main process will be a child of a frozen process (as PID 1 is from the host), and this means you have to be very very careful with what you do, since you then cannot rely on some of the most basic functions of the OS. for example, PID 1 reaps processes which get reparented to it normally. Thus in your initrd you should be very careful never to have processes die while they have children as they will collect as unreaped children of PID 1 then... One can ignore issues like that, but they are frickin ugly > >> 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. > > Again, the simplest solution would be to spawn the passphrase prompt > *before* suspend, to ensure that all required components are already in > memory. Or do you see caveats? Programs are memory mapped on Linux, i.e. nominally on disk, only the bits paged in as they are used, as they are executed. Similar, data files are typically memory mapped too. This means that preparing anything in advance is not that easy, you have to lock it into RAM too. Which you can do, but doesn't really scale, since our dep trees are large and fonts/media files in particular so. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c
On Do, 10.10.19 17:22, Jonas Meurer (jo...@freesources.org) wrote: > >> 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? No. During suspend it's likely the kernel flushes caches. This means GNOME tools previously in memory might not be anymore and would have to be paged in again when they are executed again. But that's going to hang if your too disk is paused. > > [...] 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. I disagree. In my view, immutable+non-encrypted /usr is certainly the way to go. Not sure why you'd encrypt the OS if it's Open Source anyway. /var should be locked to the TPM, and $HOME bound to the user's credentials. System resources should not be protected by user credentials. And user resources not (at least not exclusively) by system credentials. > 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? Yes. > 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. Hmm, so far this all just worked for me, I didn't run into any trouble with suspending just $HOME? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c
On Do, 10.10.19 12:01, Tim Dittler (tim.ditt...@systemli.org) wrote: > > 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 > > 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. Well, but if you have no way to acquire the password you are in trouble. You have to think about the UX at some point. You'd have to rework systemd-suspend.service (and similar services) to transition to your initrd fully, then run systemd-sleep from there I figure and then maybe have a drop-in /usr/lib/systemd/system-sleep/ that unlocks the root fs. But it's not going to be nice if there's no UI support. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c
On Mon, 14 Oct 2019 16:27:47 +0200 Jonas Meurer wrote: > Yeah, something like that was my hope as well: use plymouth and > framebuffer or something alike for spawning the passphrase prompt. FWIW, I'm just a user but I taboo plymouth on all my systems. I prefer to see the traditional scrolling messages. So I hope the mechanism would fall back to a simple password prompt. Cheers, Dave ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 entered. >> 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. Again, the simplest solution would be to spawn the passphrase prompt *before* suspend, to ensure that all required components are already in memory. Or do you see caveats? Cheers jonas signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.fre
Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c
On Thu, 10 Oct 2019 at 16:49, Mantas Mikulėnas wrote: > > On Thu, Oct 10, 2019 at 6:23 PM Jonas Meurer 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 (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. > > 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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c
On Thu, Oct 10, 2019 at 6:23 PM Jonas Meurer 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 (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? > 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?) -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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
Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c
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
Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c
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
[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
