Simon R Knight (srk@tcp.co.uk)
Wed, 17 Jun 1998 21:12:50 0000
On 17 Jun 98 at 22:06, Chris Wedgwood wrote:
> Marcus Watts wrote:
>
> > The *best* way to understand what GlobalLock/GlobalUnlock do, is to get
> > ahold of some sort of hardware 386 emulator with trace/debug features,
> > trace Windows as it executes this call, and find out what it does.
>
> This has been discussed before....
>
> GlobalLock/GlobalUnlock do not lock pages into memory. Memory that has been
> GlobalLock'd can still be paged out.
Do you know if the situation is different with page or segment locks?
> I have tested this, as has I believe Peter Gutmann and a number of other
> people. If someone wants to try this I suggest:
>
> - allocate some memory
>
> - put some patterned data into the memory
>
> - put the process to sleep
>
> - have another process allocate buffer greaters than the physical ram size
> and walk up and down these to induce heavy swapping.
>
> - kill both process and start scavenging though the swap file...
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.
> If you want unpagable memory under Windows, your going to have to do funny
> things with a VxD or some such which can presumably allocate truly locked
> memory (although I've never tried this).
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.
> Better still, use a real OS that supports mlock.
Like unix ? Doesn't mlock require superuser privileges under unix ?
As a shareware developer for Windows operating systems, I have no
desire to program for another OS. The popularity of this platform is
seeing so many encryption related products developed for it, that I
consider it important - for myself at least - to determine to what
degree the issue of virtual memory has been glossed over.
Simon R Knight
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:18:37 ADT