Re: mlock(1)

From: Nigel Cunningham
Date: Mon Sep 27 2004 - 17:21:54 EST


Hi.

On Tue, 2004-09-28 at 00:16, Andrea Arcangeli wrote:
> On Mon, Sep 27, 2004 at 08:16:43AM +0200, Stefan Seyfried wrote:
> > Andrea Arcangeli wrote:
> >
> > > random keys are exactly fine, but only for the swap usage on a desktop
> > > machine (the one I mentioned above, where the user will not be asked for
> > > a password), but it's not ok for suspend/resume, suspend/resume needs
> > > a regular password asked to the user both at suspend time and at resume
> > > time.
> >
> > Why not ask on every boot? (and yes, the passphrase could be stored on a
> > fixed disk location - hashed with a function of sufficient complexity
> > and number of bits, just to warn the user if he does a typo, couldn't
> > it?). If suspend is working, you basically never reboot. So why ask on
> > suspend _and_ resume? This also solves the "suspend on lid close" issue.
>
> 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.

> > And a resume is - in the beginning - a boot, so just ask early enough
> > (maybe the bootloader could do this?)
>
> 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.

> suspend/resume is just unusable for me on the laptop until we fix the
> crypto issues.

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

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/