Re: mlock(1)

[Andrea Arcangeli]

On Fri, Sep 24, 2004 at 10:46:32PM -0400, Valdis.Kletnieks@xxxxxx wrote:
> I think we're actually in what the IETF sometimes calls 'violent agreement' -
> what I meant was that if a misconfigured /etc/fstab marked a file system
> as 'swap', then even if it survived the 'mkswap', the subsequent swapping
> would finish the job...

indeed, I got it now ;)

> But as you noted in an earlier posting, having the metadata in cleartext
> so sys_swapon can tell what's going on and skipping the mkswap entirely is
> a better solution..

Yep.

> > or also if you mkswap on the whole device without partitions.
> 
> "Linux is designed to give you enough rope to shoot yourself in the foot with" ;)

eheh ;)

> Yes, that does sound like a sane idea, and also addresses at least *most* of
> the issues with swsusp and swap not stepping on each other's toes (as the

exactly ;)

> header is in cleartext so they both can read it). That still leaves the
> swsusp crew having to save their key securely - but that's easily done if
> you have cryptoapi handy.  Only ugly part is having to read a passphrase
> from the keyboard at suspend and resume (trying to implement "suspend on
> close lid" gets.. ummm.. interesting ;)

that's it yes.

I don't even think "save their key securely" (I mean saving anything
related to the swapsuspend encryption key on disk) is needed. A mixture
of a on-disk key + passphrase would not be more secure than a simple
"passphrase" alone, because the on-disk key would be in cleartext and
readable from the attacker. the only usable key is the one in the user memory,
it cannot be saved in the computer anywhere. Peraphs for additional
security (and to avoid having to type and remember it) one could use an
usb pen to store and fetch the key... but then I leave the fun to the
usb folks since to do that usb should kick off before resume overwrites
the kernel image ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/