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/win321099.htm&nav=/msj/1099/newnav.htm -- Peter Watkins - peterw@tux.org - peterw@usa.net - http://www.tux.org/~peterw/ Private personal mail: use PGP key F4F397A8; more sensitive data? Use 2D123692
