On Fri, Apr 15, 2005 at 11:44:06AM +0200, Andreas Steinmetz wrote:
> Matt Mackall wrote:
> > Zero only the mlocked regions. This should take essentially no time at
> > all. Swsusp knows which these are because they have to be mlocked
> > after resume as well. If it's not mlocked, it's liable to be
Pavel Machek wrote:
> Andreas, do you think you could write nice, long, FAQ entries so that
> we don't have to go through this discussion over and over?
I can do so over the weekend. Am I right that you mean the FAQ section
of Documentation/power/swsusp.txt?
BTW: would it make sense to reset the
Hi!
> > Andreas, do you think you could write nice, long, FAQ entries so that
> > we don't have to go through this discussion over and over?
>
> I can do so over the weekend. Am I right that you mean the FAQ section
> of Documentation/power/swsusp.txt?
Yes.
> BTW: would it make sense to reset t
Matt Mackall wrote:
> A much more likely vector is stealing the laptop while it's suspended.
> And the encrypted swsusp patch has -zero- security here: it writes the
> key in the header in the clear. It's rather odd that everyone's hung
> up on the "box rooted after resume" attack and completely ig
Matt Mackall wrote:
> Zero only the mlocked regions. This should take essentially no time at
> all. Swsusp knows which these are because they have to be mlocked
> after resume as well. If it's not mlocked, it's liable to be swapped
> out anyway.
Nitpicking:
What happens if the disk decides to relo
On Thu, Apr 14, 2005 at 03:11:53PM -0700, Andy Isaacson wrote:
> On Thu, Apr 14, 2005 at 12:53:52PM -0700, Matt Mackall wrote:
> > On Thu, Apr 14, 2005 at 09:27:22PM +0200, Stefan Seyfried wrote:
> > > Matt Mackall wrote:
> > > > Any sensible solution here is going to require remembering passwords.
On Thu, Apr 14, 2005 at 10:18:12PM +0200, Pavel Machek wrote:
> Hi!
>
> > > So we would need to zero out the suspend image in swap to prevent the
> > > retrieval of this data from the running machine (imagine a
> > > remote-root-hole).
> > >
> > > Zeroing out the suspend image means "write lots of
On Thu, Apr 14, 2005 at 12:53:52PM -0700, Matt Mackall wrote:
> On Thu, Apr 14, 2005 at 09:27:22PM +0200, Stefan Seyfried wrote:
> > Matt Mackall wrote:
> > > Any sensible solution here is going to require remembering passwords.
> > > And arguably anywhere the user needs encrypted suspend, they'll
Hi!
> > So we would need to zero out the suspend image in swap to prevent the
> > retrieval of this data from the running machine (imagine a
> > remote-root-hole).
> >
> > Zeroing out the suspend image means "write lots of megabytes to the
> > disk" which takes a lot of time.
>
> Zero only the ml
Hi!
> > Arguably, using dm-crypt is more secure, but it is also more
> > complicated from the Joe User POV. IMHO we should not force users to
> > set up dm-crypt, remember passwords etc., to get some basic
> > security.
>
> Any sensible solution here is going to require remembering passwords.
An
On Thu, Apr 14, 2005 at 09:27:22PM +0200, Stefan Seyfried wrote:
> Matt Mackall wrote:
>
> > Any sensible solution here is going to require remembering passwords.
> > And arguably anywhere the user needs encrypted suspend, they'll want
> > encrypted swap as well.
>
> But after entering the passwo
Matt Mackall wrote:
> Any sensible solution here is going to require remembering passwords.
> And arguably anywhere the user needs encrypted suspend, they'll want
> encrypted swap as well.
But after entering the password and resuming, the encrypted swap is
accessible again and my ssh-key may be l
On Thu, Apr 14, 2005 at 11:04:39AM +0200, Rafael J. Wysocki wrote:
> Hi,
>
> On Thursday, 14 of April 2005 10:08, Herbert Xu wrote:
> > On Thu, Apr 14, 2005 at 08:51:25AM +0200, Pavel Machek wrote:
> > >
> > > > This solution is all wrong.
> > > >
> > > > If you want security of the suspend image
Andy Isaacson <[EMAIL PROTECTED]> wrote:
> * the key is automatically regenerated every 2 hours (or whatever); as
>pages encrypted under the old key age out, it can be freed eventually
Changing the key would not help, since if you can get the swap pages on
a running system, you can also get
On Ät 14-04-05 18:08:37, Herbert Xu wrote:
> On Thu, Apr 14, 2005 at 08:51:25AM +0200, Pavel Machek wrote:
> >
> > > This solution is all wrong.
> > >
> > > If you want security of the suspend image while "suspended", encrypt
> > > with dm-crypt. If you want security of the swap image after resume
Hi,
On Thursday, 14 of April 2005 10:08, Herbert Xu wrote:
> On Thu, Apr 14, 2005 at 08:51:25AM +0200, Pavel Machek wrote:
> >
> > > This solution is all wrong.
> > >
> > > If you want security of the suspend image while "suspended", encrypt
> > > with dm-crypt. If you want security of the swap i
>
> > * the key is automatically regenerated every 2 hours (or whatever); as
> >pages encrypted under the old key age out, it can be freed eventually
>
> This'll require changes to dmcrypt but it's doable.
but it's not useful since linux actually generally keeps the pages also
in swap even
On Thu, Apr 14, 2005 at 01:31:19AM -0700, Andy Isaacson wrote:
>
> Does dmcrypt have a simple operation mode like OpenBSD's encrypted swap?
> I want to be able to 'sysctl -w kernel.swap_crypt=1' and get
It's not that easy however the distros can make it so that it's as
simple as running one comma
On Thu, Apr 14, 2005 at 09:39:04AM +1000, Herbert Xu wrote:
> > Andreas is right. They are encrypted in swap, but they should not be
> > there at all. And they are encrypted by key that is still available
> > after resume. Bad.
>
> The dmcrypt swap can only be unlocked by the user with a passphras
On Ät 14-04-05 03:13:41, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > The dmcrypt swap can only be unlocked by the user with a passphrase,
> > which is analogous to how you unlock your ssh private key stored
> > on the disk using a passphrase.
>
> We talk about the unlock
On Thu, Apr 14, 2005 at 08:51:25AM +0200, Pavel Machek wrote:
>
> > This solution is all wrong.
> >
> > If you want security of the suspend image while "suspended", encrypt
> > with dm-crypt. If you want security of the swap image after resume,
> > zero out the portion of swap used. If you want bo
Hi!
> > > > > The ssh keys are *encrypted* in the swap when dmcrypt is used.
> > > > > When the swap runs over dmcrypt all writes including those from
> > > > > swsusp are encrypted.
> > > >
> > > > Andreas is right. They are encrypted in swap, but they should not be
> > > > there at all. And the
In article <[EMAIL PROTECTED]> you wrote:
> The dmcrypt swap can only be unlocked by the user with a passphrase,
> which is analogous to how you unlock your ssh private key stored
> on the disk using a passphrase.
We talk about the unlocked system getting hacked. However I am not why the
hacker wo
In article <[EMAIL PROTECTED]> you wrote:
> The ssh keys are *encrypted* in the swap when dmcrypt is used.
> When the swap runs over dmcrypt all writes including those from
> swsusp are encrypted.
The problem is that after an resume the running system has access to the
swap, because the key is rec
On Thu, Apr 14, 2005 at 01:46:02AM +0200, Pavel Machek wrote:
> On ??t 14-04-05 09:39:04, Herbert Xu wrote:
> > On Thu, Apr 14, 2005 at 01:24:31AM +0200, Pavel Machek wrote:
> > >
> > > > The ssh keys are *encrypted* in the swap when dmcrypt is used.
> > > > When the swap runs over dmcrypt all writ
On Ät 14-04-05 09:39:04, Herbert Xu wrote:
> On Thu, Apr 14, 2005 at 01:24:31AM +0200, Pavel Machek wrote:
> >
> > > The ssh keys are *encrypted* in the swap when dmcrypt is used.
> > > When the swap runs over dmcrypt all writes including those from
> > > swsusp are encrypted.
> >
> > Andreas is r
On Thu, Apr 14, 2005 at 01:24:31AM +0200, Pavel Machek wrote:
>
> > The ssh keys are *encrypted* in the swap when dmcrypt is used.
> > When the swap runs over dmcrypt all writes including those from
> > swsusp are encrypted.
>
> Andreas is right. They are encrypted in swap, but they should not be
On Ät 14-04-05 09:10:44, Herbert Xu wrote:
> On Thu, Apr 14, 2005 at 12:29:36AM +0200, Andreas Steinmetz wrote:
> >
> > > Why is that? In the case of swap over dmcrypt, swsusp never reads/writes
> > > the disk directly. All operations are done through dmcrypt.
> > >
> > > The user has to enter a
On Thu, Apr 14, 2005 at 12:29:36AM +0200, Andreas Steinmetz wrote:
>
> > Why is that? In the case of swap over dmcrypt, swsusp never reads/writes
> > the disk directly. All operations are done through dmcrypt.
> >
> > The user has to enter a password before the system can be resumed.
>
> Think o
Herbert Xu wrote:
> On Wed, Apr 13, 2005 at 02:59:28PM +0200, Andreas Steinmetz wrote:
>
>>Herbert Xu wrote:
>>
>>>What's wrong with using swap over dmcrypt + initramfs? People have
>>>already used that to do encrypted swsusp.
>>
>>Nothing. The problem is the fact that after resume there is then
>
On Wed, Apr 13, 2005 at 02:59:28PM +0200, Andreas Steinmetz wrote:
> Herbert Xu wrote:
> > What's wrong with using swap over dmcrypt + initramfs? People have
> > already used that to do encrypted swsusp.
>
> Nothing. The problem is the fact that after resume there is then
> unencrypted(*) data on
Pavel Machek wrote:
> Applied (it is *not* going to make it into 2.6.12, and not sure about
> 2.6.13, but it is in my local tree now. You had Kconfig and docs
> changes, too, can you retransmit them?
> Pavel
No changes to config and doc
Hi!
> Here comes the next incarnation, this time against 2.6.12rc2.
> Unfortunately only compile tested as 2.6.12rc2 happily oopses away
> (vanilla from kernel.org, oops already sent to lkml).
>
> Please let me know if you want any further changes.
Applied (it is *not* going to make it into 2.6.
Herbert Xu wrote:
> What's wrong with using swap over dmcrypt + initramfs? People have
> already used that to do encrypted swsusp.
Nothing. The problem is the fact that after resume there is then
unencrypted(*) data on disk that should never have been there, e.g.
dm-crypt keys, ssh keys, ...
This
Andreas Steinmetz <[EMAIL PROTECTED]> wrote:
>
> Here comes the next incarnation, this time against 2.6.12rc2.
> Unfortunately only compile tested as 2.6.12rc2 happily oopses away
> (vanilla from kernel.org, oops already sent to lkml).
>
> Please let me know if you want any further changes.
What
Here comes the next incarnation, this time against 2.6.12rc2.
Unfortunately only compile tested as 2.6.12rc2 happily oopses away
(vanilla from kernel.org, oops already sent to lkml).
Please let me know if you want any further changes.
--
Andreas Steinmetz SPAMmers use [EMAIL
Rafael J. Wysocki wrote:
> Hi,
>
> On Monday, 11 of April 2005 18:11, Andreas Steinmetz wrote:
>
>>Pavel Machek wrote:
>>
>>>Was it really neccessary to include "union u"? I don't like its name,
>>
>>Here comes the patch with this reverted. I'm now using casts when
>>'abusing' the space for encry
Rafael J. Wysocki wrote:
> Hi,
>
> On Monday, 11 of April 2005 23:08, Pavel Machek wrote:
>
>>Hi!
>>
>
> ]--snip--[
>
@@ -130,6 +150,52 @@
static unsigned short swapfile_used[MAX_SWAPFILES];
static unsigned short root_swap;
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static struc
Hi,
On Monday, 11 of April 2005 23:08, Pavel Machek wrote:
> Hi!
>
]--snip--[
> > > @@ -130,6 +150,52 @@
> > > static unsigned short swapfile_used[MAX_SWAPFILES];
> > > static unsigned short root_swap;
> > >
> > > +#ifdef CONFIG_SWSUSP_ENCRYPT
> > > +static struct crypto_tfm *crypto_init(int
Hi!
> I had no time to review your patch earlier, sorry. I'm inlining it so that I
> can
> comment it:
> > @@ -72,6 +75,16 @@
> >
> > #include "power.h"
> >
> > +#ifdef CONFIG_SWSUSP_ENCRYPT
> > +#include
> > +#include
> > +#include
> > +#endif
> > +
> > +#define CIPHER "aes"
> > +#defi
Hi,
On Monday, 11 of April 2005 18:11, Andreas Steinmetz wrote:
> Pavel Machek wrote:
> > Was it really neccessary to include "union u"? I don't like its name,
>
> Here comes the patch with this reverted. I'm now using casts when
> 'abusing' the space for encryption. Furthermore the iv set up in
Hi!
> > I'd like to retain ability to read suspend image in any order (so that
> > code can be reused for swap encryption, etc).
>
> This is not possible with cipher block chaining as used right now. One
> would have to use a non-random iv set needs to set for every page. And
> this leads to exac
Pavel Machek wrote:
> I'd like to retain ability to read suspend image in any order (so that
> code can be reused for swap encryption, etc).
> Pavel
This is not possible with cipher block chaining as used right now. One
would have to us
Pavel Machek wrote:
> Was it really neccessary to include "union u"? I don't like its name,
Here comes the patch with this reverted. I'm now using casts when
'abusing' the space for encryption. Furthermore the iv set up in the tfm
is used instead of the local copy.
--
Andreas Steinmetz
Pavel Machek wrote:
> Hi!
>
>
>>The following patch adds the core functionality for the encrypted
>>suspend image.
>
>
> +#ifdef CONFIG_SWSUSP_ENCRYPT
> +static struct crypto_tfm *crypto_init(int mode)
> +{
> + struct crypto_tfm *tfm;
> + int len;
> +
> + tfm = crypto_alloc_tf
[EMAIL PROTECTED] wrote:
>>>The following patch adds the core functionality for the encrypted
>>>suspend image.
>>
>>[Please inline patches, it makes it easier to comment on them.]
Aiyeeh - good ole Mozilla tends to reformat things when inlining...
>>You seem to reuse same key/iv for all the bloc
> > > > The following patch adds the core functionality for the encrypted
> > > > suspend image.
> > > [Please inline patches, it makes it easier to comment on them.]
> > > You seem to reuse same key/iv for all the blocks. I'm no crypto
> > > expert, but I think that is seriously wrong... You proba
Hi!
> The following patch adds the core functionality for the encrypted
> suspend image.
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static struct crypto_tfm *crypto_init(int mode)
+{
+ struct crypto_tfm *tfm;
+ int len;
+
+ tfm = crypto_alloc_tfm(CIPHER, CRYPTO_TFM_MODE_CBC);
+ if(!tf
Hi!
> > > The following patch adds the core functionality for the encrypted
> > > suspend image.
> > [Please inline patches, it makes it easier to comment on them.]
> > You seem to reuse same key/iv for all the blocks. I'm no crypto
> > expert, but I think that is seriously wrong... You probably s
> > The following patch adds the core functionality for the encrypted
> > suspend image.
> [Please inline patches, it makes it easier to comment on them.]
> You seem to reuse same key/iv for all the blocks. I'm no crypto
> expert, but I think that is seriously wrong... You probably should use
> blo
Hi!
> The following patch adds the core functionality for the encrypted
> suspend image.
[Please inline patches, it makes it easier to comment on them.]
You seem to reuse same key/iv for all the blocks. I'm no crypto
expert, but I think that is seriously wrong... You probably should use
block nu
The following patch adds the core functionality for the encrypted
suspend image.
--
Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
--- linux-2.6.11.2/kernel/power/swsusp.c.ast2005-04-10 14:08:55.0
+0200
+++ linux-2.6.11.2/kernel/power/swsusp.c2005-04-
52 matches
Mail list logo