Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:17:19 ADT
Julian Assange (proff@iq.org)
11 May 1998 18:51:00 +1000
Eric Young <eay@cryptsoft.com> writes:
> On Sun, 10 May 1998, Peter Gutmann wrote:
> > >Windows NT supports the VirtualLock and VirtualUnlock functions, which prevent
> > >data from being swapped out to disk. Unfortunately, Windows 95 (don't know
> > >about Windows 98, but I doubt it) does not implement this functionality.
> >
> > Actually it doesn't work quite the way MS document it. Noone (and that seems
> > to include any MS people you ask) knows what it really does, but it appears to
> > be only an advisory lock since if you artficially induce thrashing, you get a
> > page fault when you try to access the VirtualLock()'d pages. I covered the
>
> I belive this is the case for just about all operating systems that have a
> 'keep in memory' system call. It is nothing to do with 'password' security,
> rather a very strong hint that we don't want the memory swapped out. Real
> Time OSs may actually implement a no swap/page policy but this is very
> dangerous on a multi-user system. Just because the system call claims to
> implement something that looks like a 'no-swap' policy, does not mean it is
> true.
>
> eric
``Real'' operating systems [like 4.4bsd] don't have this limitation:
NAME
mlock, munlock - lock (unlock) physical pages in memory
SYNOPSIS
#include <sys/types.h>
#include <sys/mman.h>
int
mlock(caddr_t addr, size_t len)
int
munlock(caddr_t addr, size_t len)
DESCRIPTION
The mlock() system call locks into memory the physical pages associated
with the virtual address range starting at addr for len bytes. The
munlock() call unlocks pages previously locked by one or more mlock()
calls. For both, the addr parameter should be aligned to a multiple of
the page size. If the len parameter is not a multiple of the page size,
it will be rounded up to be so. The entire range must be allocated.
After an mlock() call, the indicated pages will cause neither a non-resi-
dent page nor address-translation fault until they are unlocked. They
may still cause protection-violation faults or TLB-miss faults on archi-
tectures with software-managed TLBs. The physical pages remain in memory
until all locked mappings for the pages are removed. Multiple processes
may have the same physical pages locked via their own virtual address
mappings. A single process may likewise have pages multiply-locked via
different virtual mappings of the same pages or via nested mlock() calls
on the same address range. Unlocking is performed explicitly by
munlock() or implicitly by a call to munmap() which deallocates the un-
mapped address range. Locked mappings are not inherited by the child
process after a fork(2).
Since physical memory is a potentially scarce resource, processes are
limited in how much they can lock down. A single process can mlock() the
minimum of a system-wide ``wired pages'' limit and the per-process
RLIMIT_MEMLOCK resource limit.
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:17:19 ADT