Re: mlock(1)

[Valdis . Kletnieks]

On Sat, 25 Sep 2004 04:15:01 +0200, Andrea Arcangeli said:
> On Fri, Sep 24, 2004 at 09:46:59PM -0400, Valdis.Kletnieks@xxxxxx wrote:
> > On Sat, 25 Sep 2004 03:30:13 +0200, Andrea Arcangeli said:
> > > On Fri, Sep 24, 2004 at 06:21:27PM -0700, David Lang wrote:
> > > > if you don't do a -c mkswap runs fast enough that it shouldn't be a 
> > > > problem to do it every boot.
> > > 
> > > yep, speed isn't my worry, my worry is a misconfigured /etc/fstab wiping
> > > out a filesystem...
> > 
> > If the mkswap doesn't nuke the filesystem, the first time we actually
> > send a page to swap will do the job.  Plus, there's more chance of paging
> 
> how can a page be sent to swap if sys_swapon refuses to run? The whole
> point of avoiding running mkswap is to forbid sys_swapon to run.

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...

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..

> > Maybe have mkswap check the partition table and not do it if the partition
> > isn't id=82 (Linux swap) unless -f is specified?  Not sure what to do if
> > the space is a loop or LVM device though.....
> 
> 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" ;)

I'll let somebody else worry about how paranoid mkswap should be before
requiring a -f flag.

> doing crypto-swap with cryptoapi inside the swap layer (without using
> cryptoloop and dm-crypt) with a transparently randomly choosen password
> and the metadata written in cleartext sounds just a lot cleaner and
> safer.

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
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 ;)

Attachment: pgp00000.pgp
Description: PGP signature