Hi!
> > > Two things which I think would be nice to consider are:
> > > 1) Encryption - I'd actually prefer if my luks device did not
> > > remember the key accross a hibernation; I want to be forced to
> > > reenter the phrase. However I don't know what the best thing
> > > to do to partitions/applications using the luks device is.
> >
> > Encryption is possible with both the userland hibernation (aka uswsusp) and
> > TuxOnIce (formerly known as suspend2). Still, I don't consider it as a "must
> > have" feature for a framework to be generally useful (many users don't use it
> > anyway).
>
> If a user uses an encrypted filesystem, then he also needs an encrypted
> swap and encrypted hibernation image: Otherwise the fileystem encryption
> is not very useful.
Actually, we can do most of that stuff already.
We can encrypt filesystems, encrypt swaps (LVM), and encrypt hibernation.
What we _can't_ do is to hibernate on LVM encrypted partition, and we
could only suspend to swap partition. Bad combination, but here's way
out: just use separate (raw) partition for hibernation.
Ok, that needs re-partitioning; if that's bad, just swapoff before
hibernation and mkswap/swapon after its done.
Index: suspend.c
===================================================================
RCS file: /cvsroot/suspend/suspend/suspend.c,v
retrieving revision 1.82
diff -u -u -r1.82 suspend.c
--- suspend.c 29 Jul 2007 12:48:10 -0000 1.82
+++ suspend.c 5 Aug 2007 19:49:05 -0000
@@ -59,6 +59,7 @@
static unsigned long pref_image_size = IMAGE_SIZE;
static int suspend_loglevel = SUSPEND_LOGLEVEL;
static char compute_checksum;
+static int raw_partition = 1;
#ifdef CONFIG_COMPRESS
static char compress;
#else
@@ -184,6 +185,9 @@
int error;
loff_t free_swap;
+ if (raw_partition)
+ return 1*1024*1024*1024;
+
error = ioctl(dev, SNAPSHOT_AVAIL_SWAP, &free_swap);
if (!error)
return free_swap;
@@ -197,6 +201,12 @@
int error;
loff_t offset;
+ if (raw_partition) {
+ static int cur_offset = 0;
+ cur_offset += page_size;
+ return cur_offset;
+ }
+
error = ioctl(dev, SNAPSHOT_GET_SWAP_PAGE, &offset);
if (!error)
return offset;
@@ -205,6 +215,8 @@
static inline int free_swap_pages(int dev)
{
+ if (raw_partition)
+ return 0;
return ioctl(dev, SNAPSHOT_FREE_SWAP_PAGES, 0);
}
@@ -213,6 +225,8 @@
struct resume_swap_area swap;
int error;
+ if (raw_partition)
+ return 0;
swap.dev = blkdev;
swap.offset = offset;
error = ioctl(dev, SNAPSHOT_SET_SWAP_AREA, &swap);
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
* Pavel Machek ([email protected]) wrote:
> Hi!
>
> > > > Two things which I think would be nice to consider are:
> > > > 1) Encryption - I'd actually prefer if my luks device did not
> > > > remember the key accross a hibernation; I want to be forced to
> > > > reenter the phrase. However I don't know what the best thing
> > > > to do to partitions/applications using the luks device is.
> > >
> > > Encryption is possible with both the userland hibernation (aka uswsusp) and
> > > TuxOnIce (formerly known as suspend2). Still, I don't consider it as a "must
> > > have" feature for a framework to be generally useful (many users don't use it
> > > anyway).
> >
> > If a user uses an encrypted filesystem, then he also needs an encrypted
> > swap and encrypted hibernation image: Otherwise the fileystem encryption
> > is not very useful.
>
> Actually, we can do most of that stuff already.
>
> We can encrypt filesystems, encrypt swaps (LVM), and encrypt hibernation.
But can you do what my original question was; find a way to lose a luks
encrypted device key and cleanly unmount the filesystem that was
using it? (and preferably put it all back together after resume).
Dave
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
On Sunday, 12 August 2007 01:43, Dr. David Alan Gilbert wrote:
> * Pavel Machek ([email protected]) wrote:
> > Hi!
> >
> > > > > Two things which I think would be nice to consider are:
> > > > > 1) Encryption - I'd actually prefer if my luks device did not
> > > > > remember the key accross a hibernation;
Why exactly (assuming that the hibernation image is encrypted)?
Greetings,
Rafael
On 8/11/07, Dr. David Alan Gilbert <[email protected]> wrote:
> * Pavel Machek ([email protected]) wrote:
> > Hi!
> >
> > > > > Two things which I think would be nice to consider are:
> > > > > 1) Encryption - I'd actually prefer if my luks device did not
> > > > > remember the key accross a hibernation; I want to be forced to
> > > > > reenter the phrase. However I don't know what the best thing
> > > > > to do to partitions/applications using the luks device is.
> > > >
> > > > Encryption is possible with both the userland hibernation (aka uswsusp) and
> > > > TuxOnIce (formerly known as suspend2). Still, I don't consider it as a "must
> > > > have" feature for a framework to be generally useful (many users don't use it
> > > > anyway).
> > >
> > > If a user uses an encrypted filesystem, then he also needs an encrypted
> > > swap and encrypted hibernation image: Otherwise the fileystem encryption
> > > is not very useful.
> >
> > Actually, we can do most of that stuff already.
> >
> > We can encrypt filesystems, encrypt swaps (LVM), and encrypt hibernation.
>
> But can you do what my original question was; find a way to lose a luks
> encrypted device key and cleanly unmount the filesystem that was
> using it? (and preferably put it all back together after resume).
>
If you lose the device key, how are you going to get luks to find it
again when resuming? Wouldn't it make more sense to have it remember
the key? I can't see it being advisable to allow input or similar
before resume has completed...
--
Michael Chang
Please avoid sending me Word or PowerPoint attachments. Send me ODT,
RTF, or HTML instead.
See http://www.gnu.org/philosophy/no-word-attachments.html
Thank you.
Hello,
We already have a sample at:
http://wiki.tuxonice.net/EncryptedSwapAndRoot
It stores the keys of mounted partitions on an encrypted swap, which
has the same encryption with different keyset.
It also shows how to resume from encrypted swap, And you can
optionally store the keys on hardware device such as smartcards.
Best Regards,
Alon Bar-Lev
On 8/13/07, Michael Chang <[email protected]> wrote:
> On 8/11/07, Dr. David Alan Gilbert <[email protected]> wrote:
> > * Pavel Machek ([email protected]) wrote:
> > > Hi!
> > >
> > > > > > Two things which I think would be nice to consider are:
> > > > > > 1) Encryption - I'd actually prefer if my luks device did not
> > > > > > remember the key accross a hibernation; I want to be forced
> to
> > > > > > reenter the phrase. However I don't know what the best
> thing
> > > > > > to do to partitions/applications using the luks device is.
> > > > >
> > > > > Encryption is possible with both the userland hibernation (aka
> uswsusp) and
> > > > > TuxOnIce (formerly known as suspend2). Still, I don't consider it
> as a "must
> > > > > have" feature for a framework to be generally useful (many users
> don't use it
> > > > > anyway).
> > > >
> > > > If a user uses an encrypted filesystem, then he also needs an
> encrypted
> > > > swap and encrypted hibernation image: Otherwise the fileystem
> encryption
> > > > is not very useful.
> > >
> > > Actually, we can do most of that stuff already.
> > >
> > > We can encrypt filesystems, encrypt swaps (LVM), and encrypt
> hibernation.
> >
> > But can you do what my original question was; find a way to lose a luks
> > encrypted device key and cleanly unmount the filesystem that was
> > using it? (and preferably put it all back together after resume).
> >
>
> If you lose the device key, how are you going to get luks to find it
> again when resuming? Wouldn't it make more sense to have it remember
> the key? I can't see it being advisable to allow input or similar
> before resume has completed...
>
> --
> Michael Chang
>
> Please avoid sending me Word or PowerPoint attachments. Send me ODT,
> RTF, or HTML instead.
> See http://www.gnu.org/philosophy/no-word-attachments.html
> Thank you.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
* Rafael J. Wysocki ([email protected]) wrote:
> On Sunday, 12 August 2007 01:43, Dr. David Alan Gilbert wrote:
> > * Pavel Machek ([email protected]) wrote:
> > > Hi!
> > >
> > > > > > Two things which I think would be nice to consider are:
> > > > > > 1) Encryption - I'd actually prefer if my luks device did not
> > > > > > remember the key accross a hibernation;
>
> Why exactly (assuming that the hibernation image is encrypted)?
I was assuming the hibernation image was not encrypted.
Certainly if it meant a penalty during normal operation (e.g. encrypted swap)
it wouldn't be.
(I have a small amount of encrypted data in a luks partition,
most of the time it isn't used, only rarely do apps have it open
and I'm not actually worried about crawling through swap to find out
what is there - this is just a personal laptop; I appreciate these
concerns are different depending what you are storing).
Dave
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
Hi!
> > > > > > > Two things which I think would be nice to consider are:
> > > > > > > 1) Encryption - I'd actually prefer if my luks device did not
> > > > > > > remember the key accross a hibernation;
> >
> > Why exactly (assuming that the hibernation image is encrypted)?
>
> I was assuming the hibernation image was not encrypted.
> Certainly if it meant a penalty during normal operation (e.g. encrypted swap)
> it wouldn't be.
uswsusp works the way you want. Don't encrypt normal swap, and uswsusp
will still be encrypted.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html