🚀 go-pugleaf

prunesquallor wrote:
> Dear All,
> 
> I want to lock a page in memory (the reason being it will hold cryptographic 
> keys that I don't want swapped out) - so I don't want to grab much memory.
> 
> Research implies that Windows' VirtualLock will lock the page (such as the 
> MS Documentation). But we've found an early version of the MS document which 
> states that VirtualLock does not lock pages in physical memory, but in the 
> process' working set (it's notable that the modern version of the MS 
> documentation seems to be unclear). It this is the case then should the 
> whole process be slung out to disk then the locked page will go with it.

Quote from the MSDN:

<quote>
The working set of a process is the set of memory pages currently 
visible to the process in physical RAM memory. These pages are resident 
and available for an application to use without triggering a page fault. 
The minimum and maximum working set sizes affect the virtual memory 
paging behavior of a process.
</quote>

So I would conclude that locking into the working set is the same as 
locking into physical RAM.

Eelke

"Eelke" wrote:

>

> <quote>

> The working set of a process is the set of memory pages currently

> visible to the process in physical RAM memory. These pages are

> resident and available for an application to use without triggering a page 
> fault.

> The minimum and maximum working set sizes affect the virtual memory

> paging behavior of a process.

> </quote>

>

> So I would conclude that locking into the working set is the same as

> locking into physical RAM.

>

Unfortunately, I don't think it's quite that simple. That was my original 
conclusion until I found another quote on MSDN:

"Processes in Windows NT are granted subtle influence into this system 
behavior with the VirtualLock and VirtualUnlock functions. Essentially, a 
process can establish specific pages to lock into its working set. However, 
this does not give the process free reign over its working set. It cannot 
affect the number of pages that make up its working set (the system adjusts 
the working set for each process routinely), and it cannot control when the 
working set is in memory and when it is not."

That's saying that the whole lot can be shoved to disk under certain 
conditions.

That's why we're currently not convinced that VirtualLock does truly lock 
pages into physical memory.

TTFN

JB

> Unfortunately, I don't think it's quite that simple. That was my original 
> conclusion until I found another quote on MSDN:
> 
> "Processes in Windows NT are granted subtle influence into this system 
> behavior with the VirtualLock and VirtualUnlock functions. Essentially, a 
> process can establish specific pages to lock into its working set. However, 
> this does not give the process free reign over its working set. It cannot 
> affect the number of pages that make up its working set (the system adjusts 
> the working set for each process routinely), and it cannot control when the 
> working set is in memory and when it is not."
> 
> That's saying that the whole lot can be shoved to disk under certain 
> conditions.
> 
> That's why we're currently not convinced that VirtualLock does truly lock 
> pages into physical memory.

I guess Microsoft wants to prevent the possibility of bringing down a 
system by locking to much physical pages and therefor keeps the 
possibility open for swapping the workingset anyway.

In your original post you wrote
 > (the reason being it will hold cryptographic keys that I don't
 > want swapped out)
Why don't you want them to be swapped out?

Security? AFAIK memory isn't anymore secure then the swapfile.


Regards,
Eelke

"Eelke" wrote:

> I guess Microsoft wants to prevent the possibility of bringing down a 
> system by locking to much physical pages and therefor keeps the 
> possibility open for swapping the workingset anyway.
>
> In your original post you wrote
> > (the reason being it will hold cryptographic keys that I don't
> > want swapped out)
> Why don't you want them to be swapped out?
>
> Security? AFAIK memory isn't anymore secure then the swapfile.

Well, I guess it depends on the circumstances. If a key has been swapped out 
to the swap file, then it could still be there hours, days or even weeks - 
until that bit of the swap file gets overwritten. So that key is 
recoverable. Whereas a key in memory expires the next time the machine's 
off.

TTFN

JB

prunesquallor wrote:

>Well, I guess it depends on the circumstances. If a key has been swapped out 
>to the swap file, then it could still be there hours, days or even weeks - 
>until that bit of the swap file gets overwritten. So that key is 
>recoverable. Whereas a key in memory expires the next time the machine's 
>off.

Suggest to users that for better security, they buy more RAM and turn
off the swap file.

Or, don't hold the keys unencrypted in memory.

"Bob Gonder"  wrote:

> Suggest to users that for better security, they buy more RAM and turn
> off the swap file.

Yes, but I doubt the users will spend more money ... and you can't guarantee 
the swap file will never be used.

> Or, don't hold the keys unencrypted in memory.

Er ... then I can't use them! :-)

JB 

prunesquallor wrote:
> Well, I guess it depends on the circumstances. If a key has been swapped 
> out to the swap file, then it could still be there hours, days or even 
> weeks - until that bit of the swap file gets overwritten. So that key is 
> recoverable. Whereas a key in memory expires the next time the machine's 
> off.

Write over the memory with 0's. Eg:

AnsiString Key = "123456799";

DoSomething( Key );

SecureZeroMemory( Key.c_str(), Key.Length() );

HTH

Jonathan 

prunesquallor wrote:

> Well, I guess it depends on the circumstances. If a key has been swapped out 
> to the swap file, then it could still be there hours, days or even weeks - 
> until that bit of the swap file gets overwritten. So that key is 
> recoverable. Whereas a key in memory expires the next time the machine's 
> off.
> 

I had an idea that might work. The details I leave as an exercise.

If you would use a memory mapped file the block of memory would never be 
written to the swapfile. Instead windows would swap it to the file. If 
you make sure you have the file open with exclusive access (no sharing) 
to the file nobody else could get access to the contents and you could 
zero it out when you no longer needed it.

Regards,

Eelke

"Jonathan Benedicto"  wrote>
> Write over the memory with 0's. Eg:
>
> AnsiString Key = "123456799";
>
> DoSomething( Key );
>
> SecureZeroMemory( Key.c_str(), Key.Length() );

The problem is that this can happen:

AnsiString Key = "123456799";
[Process ends timeslice; machine is heavily overtasked; page including key 
thrown out to disk]
.
.
.
[Process recovered and continues when gets next timeslice]
DoSomething( Key );
SecureZeroMemory( Key.c_str(), Key.Length() );

So we end up with the key out on the disk. Whilst the probability may be 
low, one factor will be the length of time DoSomething(Key) takes - the 
longer that is, the more likely it is that at some point the key will end up 
on the disk. DoSomething() could be quite long - if a user is encrypting a 
big chunk of disk they are not going to want to type in the key/passphrase 
repeatedly.

ATB

John B

"Eelke" <e.klein@remove.mplussoftware.nl> wrote in message 
news:44112ba0$1@newsgroups.borland.com...
> I had an idea that might work. The details I leave as an exercise.
>
> If you would use a memory mapped file the block of memory would never be 
> written to the swapfile. Instead windows would swap it to the file. If you 
> make sure you have the file open with exclusive access (no sharing) to the 
> file nobody else could get access to the contents and you could zero it 
> out when you no longer needed it.

A nice idea. A skim read of:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dngenlib/html/msdn_manamemo.asp
implies that it may well work (even though it does rabbit on about the 
pagefile).

Will investigate further - thanks.

John B

prunesquallor wrote:
> [Process ends timeslice; machine is heavily overtasked; page including key 
> thrown out to disk]

Yeah, I see. That wouldn't help then.

Here is another idea. Use file mapping. Memory-map your own file on the 
drive, that you overwrite with random data 7 times when finished.

Mind you, I didn't just pick 7, the US DoD suggests that as minimal.

Jonathan 

prunesquallor wrote:
> A nice idea. A skim read of:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dngenlib/html/msdn_manamemo.asp
> implies that it may well work (even though it does rabbit on about the 
> pagefile).

I read this after posting my post :-(. Don't overwrite with 0's use random 
data, it is much safer.

HTH

Jonathan