Linux suspend

On Monday 05 June 2006 21:52, Jason Lunz wrote:
> On Mon, Jun 05, 2006 at 08:51:48PM +0200, Pavel Machek wrote:
> > Sorry, I confused you. Yes, there's a password, but only on
> > resume. Can dm-crypt replicate that? (No password on boot or during
> > suspend?)
> 
> sorry, I never answered your question. I presume the goal here is to
> make sure that mlock()ed data that would never otherwise be written to
> disk isn't put on disk unprotected as part of suspend, while at the same
> time not bothering the user about passwords and keys? That would make
> sense.

Yes, exactly. :-)

> cryptsetup supports supplying the key in a file, so I suppose this is
> possible in theory.  But you would have to recreate the swap partition
> on each suspend/resume cycle in order to not store the key on disk any
> longer than necessary. That probably would be bad for performance. Or
> good, depending on how you feel about everything being swapped out after
> a resume :)
> 
> so yes, if the user is only interested in transparently encrypting the
> suspend image and nothing else, then it definitely makes sense to
> support encryption in ususpend. To me, the minor benefit isn't worth it
> given how much other stuff is on disk unencrypted. But i'm sure some
> disagree.

The mlocked areas may contain ssh private keys in the plain (think ssh-agent)
or some such.

Besides, in fact, for me the main reason to use the encryption is that I need
not protect the console or X sessions by any other means.  That is, if the
password is not required to decrypt the image and someone unauthorized
happens to resume the box, he will get access to the session that was open
before suspend unless the session itself is protected somehow (eg. with a
password-protected screensaver).

Greetings,
Rafael


-- 
Now some men hustle and some just think.
And some go running before you blink.
Some look up and some look down
from three hundred feet above the ground.
		Ian Anderson - "Steel Monkey"

On Mon, Jun 05, 2006 at 08:51:48PM +0200, Pavel Machek wrote:
> Sorry, I confused you. Yes, there's a password, but only on
> resume. Can dm-crypt replicate that? (No password on boot or during
> suspend?)

If you've set up dm-crypted swap, you need to enter the password both at
boot time and at resume time. Never at suspend - only when the crypted
swap is first set up.

If you use the luks extension (and it looks like that's quickly becoming
the norm), there's actually a fair bit of flexibility. The actual
blockdev encryption key is encrypted with one or more passwords, and the
password you enter at boot time therefore only indirectly decrypts the
partition (by giving access to the real key).

I'm currently not using a random swap key per-boot, because I also have
dm-crypted root and it's easier to simply treat both of the encrypted
partitions the same.

That's really the nice thing about dm-crypt - it's general. Once you've
learned to dm-crypt your swap and get access to it at boot time within
your initramfs, it isn't much of a leap to do this to your root
partition as well.

What you end up with, then, is a laptop where *all* on-disk data is
encrypted at *all times*, which is really the ultimate goal if you're
trying to protect against physical data loss, right?

I have 3 partitions on the laptop - /boot, swap, and /. Only /boot is
ever unencrypted, whether the machine is running, suspended, or off.

I guess that's what bugs me about doing encryption in ususpend - it only
gets you partway to this, then it's a dead end and you have to go to
dm-crypt anyway to get full protection.

anyway, i'm not trying to argue about it. I don't mind if you keep your
encryption code, Rafael. :)  I agree it does make sense if your paranoia
is more limited... your point about mlock() is good.  I'm just
explaining my thinking about this.

Jason

On Mon, Jun 05, 2006 at 08:51:48PM +0200, Pavel Machek wrote:
> Sorry, I confused you. Yes, there's a password, but only on
> resume. Can dm-crypt replicate that? (No password on boot or during
> suspend?)

sorry, I never answered your question. I presume the goal here is to
make sure that mlock()ed data that would never otherwise be written to
disk isn't put on disk unprotected as part of suspend, while at the same
time not bothering the user about passwords and keys? That would make
sense.

cryptsetup supports supplying the key in a file, so I suppose this is
possible in theory.  But you would have to recreate the swap partition
on each suspend/resume cycle in order to not store the key on disk any
longer than necessary. That probably would be bad for performance. Or
good, depending on how you feel about everything being swapped out after
a resume :)

so yes, if the user is only interested in transparently encrypting the
suspend image and nothing else, then it definitely makes sense to
support encryption in ususpend. To me, the minor benefit isn't worth it
given how much other stuff is on disk unencrypted. But i'm sure some
disagree.

Jason

On Monday 05 June 2006 23:10, Jason Lunz wrote:
> On Mon, Jun 05, 2006 at 10:51:00PM +0200, Rafael J. Wysocki wrote:
> > Besides, in fact, for me the main reason to use the encryption is that I need
> > not protect the console or X sessions by any other means.  That is, if the
> > password is not required to decrypt the image and someone unauthorized
> > happens to resume the box, he will get access to the session that was open
> > before suspend unless the session itself is protected somehow (eg. with a
> > password-protected screensaver).
> 
> I'm not sure I follow you. You're saying that it's a good thing you have
> to enter a password on resume, because that way you never have to bother
> with xlock or the like prior to resume? IOW, your mlock ssh keys are
> safe if the laptop is stolen while suspended.

To me these are two different things.

First, the ssh private keys.  Well, I'd like them to be safe if the box is
stolen while suspended.  They aren't stored on disk in the plain or swapped
out, although I don't encrypt just everything.  Now if they are written in the
plain to the suspend image, their security will be affected by the very fact
that the machine gets suspended.  Hence for a user who doesn't use dm-crypt
the lack of encryption in ususpend would affect the security and the user
should not be forced to use additional mechanisms to _restore_ the level of
security he/she would have if he/she didn't suspend.

Second, the password.  Of course it's needed for the decryption, but it also
helps you protect the box from unauthorized access if it's not stolen.

Assume, for example, that you leave the suspended box somewhere unattended for
some time and in such a state that it's diffucult to steal it (eg. in an office
that's easily accessible to the cleaning staff etc).  Someone who wants to
access the box may have only a little time to try to resume it and access the
session that was active when the box got suspended.  Of course he/she shouldn't
be able to do this.  [Now you can protect the session with some other
mechanism, but that's a little burdensome and if this is an X session w/ KDE,
it takes quite a bit more time to get the session back when it's protected
with a screensaver. ;-)  Moreover, there may be an active root session you
forgot about on a text VT. ;-)) ]

> That's good, but in that respect it's no better or worse than dm-crypt.
> In both cases, a password is needed in order to decrypt the suspend
> image.  It's what I do also - I know that as long as the machine is off
> or suspended, everything is encrypted.
> 
> Using dm-crypt on swap adds the feature that swapped out data is
> protected in addition to suspend images. That's nice because you don't
> even have to worry if all apps properly mlock() sensitive data or not.

OTOH it adds another layer of complexity to the entire swap mechanism.

> And dm-crypted root of course protects everything else.

I don't trust encryption as much as to do this. ;-)

> of course, none of these methods protects your data if the laptop is
> stolen while it's *running*: 
> 
> http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2006/04/08/MNGE9I686K1.DTL

Agreed.

Greetings,
Rafael


-- 
Now some men hustle and some just think.
And some go running before you blink.
Some look up and some look down
from three hundred feet above the ground.
		Ian Anderson - "Steel Monkey"

On Mon, Jun 05, 2006 at 06:30:13PM +0200, Rafael J. Wysocki wrote:
> With dm-crypted swap it _is_ redundant, but it is not redundant if the swap is
> not dm-crypted.  Actually, for example, I don't care whether my swap is
> encrypted, but I do care if my suspend images are encrypted.
> 
> I don't think it would be a good idea to _require_ people to set up dm-crypted
> swap partitions just in order to be able to protect suspend images.  That's
> why there's the option to use encryption in ususpend.

have you tried it? it's trivial. It would be another matter if switching
to dm-crypt were the thing that required the user to set up an
initramfs.  But we're talking about ususpend - it's already a given that
they're using an initramfs. So they only need to add cryptsetup to their
initramfs and change the swap config, and that's it.

iirc, for me it was:

1. install cryptsetup
2. swapoff -a
3. cryptsetup luksFormat /dev/hda2
4. cryptsetup luksOpen /dev/hda2 swap
5. change /dev/hda2 -> /dev/mapper/swap in /etc/fstab
6. swapon -a

Then you need to set up initramfs to run cryptsetup before triggering
resume, but there's already support for that in yaird in debian
unstable. It happens automatically, you just need to regenerate the
initramfs image. (though there *isn't* currently support for ususpend -
I had to add that myself).

So no, I don't think it's such a bad idea to require dm-crypt when
encryption is desired. It's confusing for there to be so many options.
It would be nice to remove the ones that are (mostly) redundant.

Jason

On Mon, Jun 05, 2006 at 10:51:00PM +0200, Rafael J. Wysocki wrote:
> Besides, in fact, for me the main reason to use the encryption is that I need
> not protect the console or X sessions by any other means.  That is, if the
> password is not required to decrypt the image and someone unauthorized
> happens to resume the box, he will get access to the session that was open
> before suspend unless the session itself is protected somehow (eg. with a
> password-protected screensaver).

I'm not sure I follow you. You're saying that it's a good thing you have
to enter a password on resume, because that way you never have to bother
with xlock or the like prior to resume? IOW, your mlock ssh keys are
safe if the laptop is stolen while suspended.

That's good, but in that respect it's no better or worse than dm-crypt.
In both cases, a password is needed in order to decrypt the suspend
image.  It's what I do also - I know that as long as the machine is off
or suspended, everything is encrypted.

Using dm-crypt on swap adds the feature that swapped out data is
protected in addition to suspend images. That's nice because you don't
even have to worry if all apps properly mlock() sensitive data or not.
And dm-crypted root of course protects everything else.

of course, none of these methods protects your data if the laptop is
stolen while it's *running*: 

http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2006/04/08/MNGE9I686K1.DTL

Jason

On Tue, Jun 06, 2006 at 12:00:25AM +0200, Rafael J. Wysocki wrote:
> OTOH it adds another layer of complexity to the entire swap mechanism.

This is true, but my experience has shown it isn't much worse than
ususpend is in the first place. If you've already got to set up a custom
initramfs, it's not much harder to add cryptsetup to it.

The mapped device really just acts like a normal block device once the
mapping is in place. Come to think of it, it's a little surprising to me
now that it works so well considering that none of the main suspend
developers seems to use dm-crypt - I wasn't aware of that when I set all
this up. But I guess it shouldn't be surprising if dm devices are just
another block device.

otoh, cryptsetup is quite new, and the luks patches to it even newer.
And if cryptsetup didn't exist, we would be dealing with raw dmsetup,
which is even worse.

fortunately, things aren't so bad. It really boils down to a few
commands: 'cryptsetup luksFormat /dev/hda1' once, when you first set up
your swap partition, and 'cryptsetup luksOpen /dev/hda1 swap' whenever
you boot or resume. This second one asks for a password, and creates
/dev/mapper/swap.

> > And dm-crypted root of course protects everything else.
> I don't trust encryption as much as to do this. ;-)

I was suspicious too, but I've found that once you've set it up, you
never notice any difference. Except entering the passwords at boot, of
course. And I've been testing patches to the bcm43xx driver lately,
which means repeatedly crashing the kernel with irq races. I haven't had
any problems at all, just normal ext3 'replaying journal' stuff.

Jason

On Monday 05 June 2006 18:46, Jason Lunz wrote:
> On Mon, Jun 05, 2006 at 06:30:13PM +0200, Rafael J. Wysocki wrote:
> > With dm-crypted swap it _is_ redundant, but it is not redundant if the swap is
> > not dm-crypted.  Actually, for example, I don't care whether my swap is
> > encrypted, but I do care if my suspend images are encrypted.
> > 
> > I don't think it would be a good idea to _require_ people to set up dm-crypted
> > swap partitions just in order to be able to protect suspend images.  That's
> > why there's the option to use encryption in ususpend.
> 
> have you tried it? it's trivial. It would be another matter if switching
> to dm-crypt were the thing that required the user to set up an
> initramfs.  But we're talking about ususpend - it's already a given that
> they're using an initramfs. So they only need to add cryptsetup to their
> initramfs and change the swap config, and that's it.
> 
> iirc, for me it was:
> 
> 1. install cryptsetup
> 2. swapoff -a
> 3. cryptsetup luksFormat /dev/hda2
> 4. cryptsetup luksOpen /dev/hda2 swap
> 5. change /dev/hda2 -> /dev/mapper/swap in /etc/fstab
> 6. swapon -a
> 
> Then you need to set up initramfs to run cryptsetup before triggering
> resume, but there's already support for that in yaird in debian
> unstable. It happens automatically, you just need to regenerate the
> initramfs image. (though there *isn't* currently support for ususpend -
> I had to add that myself).
> 
> So no, I don't think it's such a bad idea to require dm-crypt when
> encryption is desired. It's confusing for there to be so many options.
> It would be nice to remove the ones that are (mostly) redundant.

Just let me say I don't agree with that last sentence and so the support
for encryption in ususpend is going to stay.

Greetings,
Rafael


-- 
Now some men hustle and some just think.
And some go running before you blink.
Some look up and some look down
from three hundred feet above the ground.
		Ian Anderson - "Steel Monkey"

On Monday 05 June 2006 18:16, Jason Lunz wrote:
> 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.

True.  Still dm-crypt does more than just 1) and 2) and that need not be
necessary for many users.

> > And the password is only required to resume.
> 
> Interesting - Pavel said there was *not* a password. Maybe /sbin/resume
> supports both options?

No.

> 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.

With dm-crypted swap it _is_ redundant, but it is not redundant if the swap is
not dm-crypted.  Actually, for example, I don't care whether my swap is
encrypted, but I do care if my suspend images are encrypted.

I don't think it would be a good idea to _require_ people to set up dm-crypted
swap partitions just in order to be able to protect suspend images.  That's
why there's the option to use encryption in ususpend.

Greetings,
Rafael


-- 
Now some men hustle and some just think.
And some go running before you blink.
Some look up and some look down
from three hundred feet above the ground.
		Ian Anderson - "Steel Monkey"

Hi!

> Just wanted to let you guys know that your new userspace suspend
> implementation is working great for me. Thanks for the great work!
> 
> Is there a mailing list for discussing this stuff? It all seems rather
> new.

Yes, now cc-ed.

> I've tried it with and without lzf compression - both work fine. I
> haven't tried the encryption, because I'm already suspending to a
> dm-crypted swap partition. I'm using linux 2.6.17-rc5-git11 currently.
> 
> [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?]

Yes, we are doing without password.

> 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.

Nigel, it would be nice to solve this one somehow...
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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. :)

Jason

On Tuesday 06 June 2006 00:52, Jason Lunz wrote:
> On Tue, Jun 06, 2006 at 12:00:25AM +0200, Rafael J. Wysocki wrote:
> > > And dm-crypted root of course protects everything else.
> > I don't trust encryption as much as to do this. ;-)
> 
> I was suspicious too, but I've found that once you've set it up, you
> never notice any difference. Except entering the passwords at boot, of
> course. And I've been testing patches to the bcm43xx driver lately,
> which means repeatedly crashing the kernel with irq races. I haven't had
> any problems at all, just normal ext3 'replaying journal' stuff.

Well, it may be much worse if your disk fails and you want to recover some
data from it anyway, or if you happen to have a faulty RAM that tends to
generate random patterns once in a while.

Greetings,
Rafael
 

-- 
Now some men hustle and some just think.
And some go running before you blink.
Some look up and some look down
from three hundred feet above the ground.
		Ian Anderson - "Steel Monkey"

On Po 05-06-06 12:19:52, Jason Lunz wrote:
> On Mon, Jun 05, 2006 at 11:36:45AM +0200, Pavel Machek wrote:
> > > Is there a mailing list for discussing this stuff? It all seems rather
> > > new.
> > 
> > Yes, now cc-ed.
> 
> btw - it'd be nice to mention the mailing list on the
> http://suspend.sourceforge.net/ site.

Luca, do you think you could add such link? Or perhaps more visible
link to sourceforge project pages in main menu?
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Il Fri, Jun 09, 2006 at 12:12:28PM +0200, Pavel Machek ha scritto: 
> On Po 05-06-06 12:19:52, Jason Lunz wrote:
> > On Mon, Jun 05, 2006 at 11:36:45AM +0200, Pavel Machek wrote:
> > > > Is there a mailing list for discussing this stuff? It all seems rather
> > > > new.
> > > 
> > > Yes, now cc-ed.
> > 
> > btw - it'd be nice to mention the mailing list on the
> > http://suspend.sourceforge.net/ site.
> 
> Luca, do you think you could add such link?

I'm on it.

Luca
-- 
Home: http://kronoz.cjb.net
Runtime error 6D at f000:a12f : user incompetente