Re: mlock(1)

[Andrea Arcangeli <andrea@novell.com>]

On Tue, Sep 28, 2004 at 08:22:41AM +1000, Nigel Cunningham wrote:
> > because I never use suspend/resume on my desktop, I never shutdown my
> > desktop. I don't see why should I spend time typing a password when
> > there's no need to. Every single guy out there will complain at linux
> > hanging during boot asking for password before reaching kdm.
> > 
> > I figured out how to make the swap encryption completely transparent to
> > userspace, and even to swap suspend, so I think it's much better than
> > having userspace asking the user for a password, or userspace choosing a
> > random password.
> 
> The public/private key idea makes good sense to me.

yes for suspend/resume it should work. it will have the only advantage
of not having to ask the password during suspend or during boot, it will
only ask the "resueme" password during resume and the first time you
create the public key for resume to write it in the harddisk encrypted
with such passphrase as . as usual it'll be as Wolfgang suggested.

But why did you quote the above? for cryptoswap it cannot work, for
cryptoswap there's no reason to ever ask the user to anything and it
must read and write all the time anyways, it's not like suspend
write-only and resume read-only, a problem where public/private
encryption can fit.

> > yes, but the bootloader passes the paramters via /proc/cmdline, and it's
> > not nice to show the password in cleartext there.
> 
> If this password is only needed when resuming, that's not an issue
> because the command line given when resuming will be lost when the
> original kernel data is copied back.

my point is that you would not be allowed to give anyone ssh access to
your machine (assuming you trust local security). If he gets ssh access,
then he could as well stole the laptop and read the encrypted data.

But if calling set_fs(KERNEL_DS); sys_read(0) sounds troublesome, you
could also erase the password from the cmdline, and you would still
pass the passphrase via bootloader. I'd recommend not to make it visible
to userspace.

> There's already compression support. It's simpler to reverse, of course,
> but it doesn't help?

that should be trivial to reverse, no?