Re: mlock(1)

[Nigel Cunningham]

Howdy.

On Sat, 2004-09-25 at 11:07, Andrea Arcangeli wrote:
> We could use the cryptoloop or dm-crypto and everything would work fine
> if we were ok to re-run mkswap after every reboot (right after choosing
> the random password). But it sounds just simpler to leave the swap
> header in cleartext. The swap header and the swap metadata in general,
> are the only thing that can be written in cleartext safely.
> 
> So when suspend kicks in, it will have only to write by hand into the
> swap device, using the a secondary password asked to the user by the
> suspend procedure. This will be the only password asked to the user.

Yes, that's exactly what I was thinking too: header & metadata in plain
text, data proper encrypted. Fits perfectly with suspend's current modus
operandi too.

> Resume will then ask the user for the same password again. It'd be also
> nice to waste 4k of swap space have a check to know if the resume
> password is ok and to avoid a kernel crash if I do a typo ;). Not being
> able to resume is still nicer than a potentially (though very unlikely)
> fs-corrupting kernel crash.

There must be some way of being able to check the password is correct
without compromising security by encrypting static text and storing it
at a known location! Darned if I know what it is though.

> This I believe should work safely. As far as suspend is concerned we
> could also use cryptoloop instead of interfacing swap directly with
> cryptoapi, then suspend should simply overwrite the swap header and
> resume should reistantiate it (could even be saved in encrypted form in
> another suspend-block), but then we'd need to run mkswap every boot and
> that's not nice. Leaving the swap metadata in cleartext sounds a lot
> nicer to avoid mkswap and to still choose random swap password at every
> reboot.

Perhaps it will help here to say that suspend plays nicely with swapping
at the moment. All of the implementations use the normal swap allocation
routines to get and free the pages they write to, and they also only
change (reverseably) the ten-character header on the header page (not
the data itself). (The SWAP-SPACE or SWAPSPACE2 sig). You thus don't
have to re-mkswap after suspending. Writing the image is done using
submit_bio, not the swapspace specific routines.

Regards,

Nigel


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