Re:[PATCH] zero disk pages used by swsusp on resume

Re:[PATCH] zero disk pages used by swsusp on resume

[Pavel Machek]

Hi! What about doing it right? Encrypt it with symmetric cypher and store key in suspend header. That way key is removed automagically while fixing signatures. No need to clear anythink. OTOH we may want to dm-crypt whole swap partition. You could still store key in header... --p

-- pavel. Sent from  mobile phone. Sorry for poor formatting.

Re: [PATCH] zero disk pages used by swsusp on resume

[Andreas Steinmetz]

[reformatted]

Pavel Machek wrote:
> Hi! What about doing it right? Encrypt it with symmetric cypher
> and store key in suspend header. That way key is removed automagically
> while fixing signatures. No need to clear anythink.

Good idea. I'll have a look though it will take a while (busy with my job).

> OTOH we may want to dm-crypt whole swap partition.

This would leave the problem that the in-kernel data would be accessible
on the swap device after resume.

> You could still store key in header... --p

Which is the good idea from step one above.

> 
> -- pavel. Sent from  mobile phone. Sorry for poor formatting.

The only remark I do have here is that swsusp would then depend on
crypto so the swsusp encryption should be a config option.
-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de

Re: [PATCH] zero disk pages used by swsusp on resume

[Pavel Machek]

Hi!

> > Hi! What about doing it right? Encrypt it with symmetric cypher
> > and store key in suspend header. That way key is removed automagically
> > while fixing signatures. No need to clear anythink.
> 
> Good idea. I'll have a look though it will take a while (busy with my job).
> 
> > OTOH we may want to dm-crypt whole swap partition.
> 
> This would leave the problem that the in-kernel data would be accessible
> on the swap device after resume.

I meant "when dm-crypt is used, encrypting swsusp data with second key
is no longer _that_ nice"...

So perhaps we should encrypt swap by default with random key, and
reuse same code for swsusp...

> > -- pavel. Sent from  mobile phone. Sorry for poor formatting.
> 
> The only remark I do have here is that swsusp would then depend on
> crypto so the swsusp encryption should be a config option.

Yes. Not evereyone has so fast CPU that encryption is NOP.

								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

Re: [PATCH] zero disk pages used by swsusp on resume

[Oliver Neukum]

> > > Hi! What about doing it right? Encrypt it with symmetric cypher
> > > and store key in suspend header. That way key is removed automagically
> > > while fixing signatures. No need to clear anythink.

You might want to leave the key in the kernel image. You need to boot the
same image anyway. Leaving the key in the header will not increase
security while the os is down.

	Regards
		Oliver

Re: [PATCH] zero disk pages used by swsusp on resume

[Pavel Machek]

Hi!

> > > > Hi! What about doing it right? Encrypt it with symmetric cypher
> > > > and store key in suspend header. That way key is removed automagically
> > > > while fixing signatures. No need to clear anythink.
> 
> You might want to leave the key in the kernel image. You need to boot the
> same image anyway. Leaving the key in the header will not increase
> security while the os is down.

I believe leaving it in the header will be easier, and it is more
easily wiped, there, too.

If suspend fails, and user boots with noresume and mkswaps, key in
header will get rewritten, too. Good.
									Pavel

-- 
Boycott Kodak -- for their patent abuse against Java.

Re: [PATCH] zero disk pages used by swsusp on resume

[Andreas Steinmetz]

Pavel Machek wrote:
> Hi!
> 
> 
>>>Hi! What about doing it right? Encrypt it with symmetric cypher
>>>and store key in suspend header. That way key is removed automagically
>>>while fixing signatures. No need to clear anythink.
>>
>>Good idea. I'll have a look though it will take a while (busy with my job).
>>
>>
>>>OTOH we may want to dm-crypt whole swap partition.
>>
>>This would leave the problem that the in-kernel data would be accessible
>>on the swap device after resume.
> 
> 
> I meant "when dm-crypt is used, encrypting swsusp data with second key
> is no longer _that_ nice"...

Hmm, thinking of a future swsusp2 with initrd capabilites encrption of
the suspend image itself is still useful to prevent data gathering after
resume. Using dm-crypt for encryption of the swap partition in this case
is useful during resume so this fits nicely together.

BTW: I spent my day on implementing the encryption of the suspend image
and will send patches after a few more tests.
-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de