On Mon, Nov 18, 2002 at 04:36:57PM +0000, Richard Moore wrote:
> Nicholas Weaver wrote:
> > On Thu, Nov 14, 2002 at 02:44:58AM -0800, Michael Wojcik composed:
> > The bigger concern is when the memory is paged to disk, and that
> > record may have a much MUCH longer time window. But scrubbing has no
> > real effect on this

> It's worth noting that on systems such as linux and solaris, it is easy
> to avoid the paging problem by locking the process into memory. This is
> accomplished using the system calls mlock(2) and mlockall(2).

Nice idea, except mlock() and mlockall() are only permissable when the
effective userid is that of the superuser. (We touched on this a while back
when discussing GnuPG; IIRC, in general Unix systems don't allow regular
user processes to lock memory pages, while Windows' win32 API does allow
such behavior.[0])

-Peter

[0] The good news is that win32 has a setting for allowing user processes
to lock pages that is distinct from the effective userid/gid; the bad news
is that it's set per-user instead of per app; to allow users to run apps
that insist on physical pages for memory allocation, it looks like you have
to grant them the ability to effectively DoS the machine by grabbing all
its physical memory. Oops.
http://www.microsoft.com/msj/defaultframe.asp?page=/msj/1099/win32/win32
1099.htm&nav=/msj/1099/newnav.htm

--
Peter Watkins - peterw (at) tux (dot) org [email concealed] - peterw (at) usa (dot) net [email concealed] - http://www.tux.org/~peterw/
Private personal mail: use PGP key F4F397A8; more sensitive data? Use 2D123692

[ reply ]