On Mon, Jun 05, 2006 at 11:48:38AM +0200, Rafael J. Wysocki wrote:
> > [I'm thinking if you want to keep things simple, you could even remove
> > the encryption support from your tool entirely -- it's nice, but
> > dm-crypt is superior because the swap is encrypted both during suspend
> > and at runtime. otoh, it requires a password - yours probably doesn't?
> > I'd suspect you just generate a random key at suspend time, right?]
> Well, if you've set up dm-crypt already, you don't need "our" encryption,
> but some people (including me ;-) ) don't use dm-crypt. There are (at least)
> two reasons why the encryption in the userland suspend tools may be useful to
> someone who doesn't use dm-crypt:
> 1) it protects data that normally wouldn't be swapped out (like those in
> mlocked memory areas),
> 2) it prevents unauthorized people from resuming the box (so eg. you can
> suspend in the middle of a root session safely).
These are both true of dm-crypted swap, as well. When you use dm-crypt
swap, your swap is encrypted at runtime, *and* your suspend image is
encrypted when you suspend.
> And the password is only required to resume.
Interesting - Pavel said there was *not* a password. Maybe /sbin/resume
supports both options?
I don't especially care either way, but it still seems to me that doing
encryption in ususpend is completely redundant with dm-crypt swap, with
the exception of passwordless operation. Both require boot with an
initrd, both require a dedicated swap partition.
> > One thing you may want to warn your users about -- Nigel's suspend2
> > patches break the in-kernel /dev/snapshot functionality. My first
> > attempt at using ususpend was on a kernel with the suspend2 patch. The
> > first try, while running everything (and in X) resulted in a crash while
> > writing the snapshot. It seemed that the system wasn't frozen! after the
> > crash, various progs were still writing to the console.
> > So my second try on the suspend2 kernel was to do the minimal vga-only,
> > unload-all-modules thing. That time it suspended, and appeared to resume
> > OK, but the system was frozen after that.
> > On a kernel without the suspend2 patch, everything works fine.
> Well, I think we should tell Nigel about this, so I've added him to
> the Cc list. ;-)
I wanted to get a proper bug report together, and maybe a photo of the
oops, before bothering Nigel. But I seem to have run out of weekend. :)