Re: [PATCH encrypted swsusp 1/3] core functionality

[Andy Isaacson <adi@hexapodia.org>]

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 want
> > > encrypted swap as well.
> > 
> > But after entering the password and resuming, the encrypted swap is
> > accessible again and my ssh-key may be lying around in it, right?
> 
> No. Because it's been zeroed in the resume process.

Zeroing the entire swsusp region is a big job, especially if you want to
do it in a FIPS-conformant manner.  Hard to test that you've done it
right and not missed any bits.

Much much easier to securely erase just the key storage.

And unless I'm missing something, you meant to say "it will have been
zeroed" (after the patch under discussion is merged), right?  The
current state of the art (as of 2.6.12-rc2) is that mlocked regions are
written to the swsusp region and may linger there indefinitely after
resume.

(I haven't read the code, that's just my understanding of the
discussion.)

> > Zeroing out the suspend image means "write lots of megabytes to the
> > disk" which takes a lot of time.
> 
> 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.

Ooof, that sounds complicated and error-prone, and likely to break
silently (a la input entropy gathering).

-andy