Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:18:38 ADT
Chris Wedgwood (chris@cybernet.co.nz)
Wed, 17 Jun 1998 18:53:25 -0400
On Wed, Jun 17, 1998 at 09:12:50PM +0000, Simon R Knight wrote:
> Do you know if the situation is different with page or segment locks?
AFAIK there is presently no way using the Win16/Win32 APIs to mark memory as
non-pagable.
It certainly does seem possible within a VxD under Windows 95, although I
never actually managed to see whether or not I could access this memory from
an application.
I'm not so sure about NT device drivers. I had a look at these back in the
3.51 days and printed out about 5 trees worth of documentation before
getting bored and doing something else.
> I have considered doing this, although I was hoping to discover a
> pre-existing analysis of this kind. As there are an increasing number of
> cryptographic implementations/libraries available for the Intel processor,
> I imagined that this issue must have been treated in some depth, although
> I have encountered no papers to support this.
An analysis of this might appear at a later date. I had some test code and
stuff which might be worth re-visiting (if I can find it) and re-working
with some of the suggestions made by various people on how to minimise the
risks of data being spuriously paged out. I also never tested NT 5 or
Windows 98, which merit testing although I assume the situation is no
different that for '95 and 'NT.
This is actually a wider issue than data just being pages out, Peter Gutmann
wrote a paper on data erasure/data persistence which makes for good reading.
Check http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html for more
details.
> I can devise a series of procedures that will monitor what actually occurs
> in memory under the different Windows operating systems and modes, but if
> a paper (or papers) already exist in the public domain, then I would
> prefer to study these first.
Monitoring the system probably isn't good enough. In fact, its likely doomed
to fail under some circumstances, mainly because any user can set their
process priority to be real time (or very near so for NT4 SP1 and later).
Because of this, its not impossible for an ActiveX control, application or
whatever to do so, then consume vast amounts of ram before your monitoring
code can detect this.
Of course, it also means your application could spawn a thread at real-time
priority that does something like:
volatile char x;
for(;!app_exit;){
/* touch important pages */
for(m=page_head;m;m=m->next)
x = m->addr[0];
/* sleep - but not for long, here 10ms */
usleep(10 * 1000);
}
but presumably this isn't fool proof, it only shrinks the window of
opportunity. You would also have to make sure the compiler doesn't optimise
'x = m->addr[0]' out.
> Like unix ? Doesn't mlock require superuser privileges under unix ?
Yes, only uid==0 can use mlock, which is a bit of a nuisance in some
circumstances (like if you want to run PGP or some such of a machine you
don't have administration permissions on, and therefore can't make it suid
or whatever).
> As a shareware developer for Windows operating systems, I have no
> desire to program for another OS.
Just stirring....
-cw
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:18:38 ADT