Forcing data into RAM memory only?
hexa
I'm currently developing an open source tool for better privacy online
and offline; it would be very important, however, to prevent disk
swapping for this application, so that no sensible data gets written
to disk unless the program wants to write it.
I was wondering if it is possible to use APIs (or something else) to
force Windows to stop any disk swapping activity for this particular
application (using only available RAM memory, no virtual memory.)
Any suggestions on how i could accomplish this task?
Is it possible to do this using VirtualAlloc's MEM_PHYSICAL?
Thanks in advance,
Z.M.
anton bassov
I am afraid you don't fully understand the basic concepts of Windows memory
management. What do you mean by saying " to force Windows to stop any disk
swapping activity for this particular application (using only available RAM
memory, no virtual memory.)"????
What you should do is to lock the pages that you want to stay resident in
RAM with ZwLockVirtualMemory(), and write all sensitive data only to these
pages - by locking them in memory, you will ensure that they will stay in
physical RAM until you either unlock them, or your application terminates.
MSDN says that this task can be accomplished by VirtualLock(), but, as I
have discovered via disassembly, VirtualLock() locks pages only in the
working set list, rather than in RAM (internally it calls
ZwLockVirtualMemory() with LOCK_VM_IN_WSL flag, i.e. LOCK_VM_IN_RAM flag is
not specified). Therefore, it looks like pages that are locked with
VirtualLock() may get paged if the system is low on memory, so that
ZwLockVirtualMemory()seems to be more reliable option, although undocumented
one (I can already foresee furious outbursts on this thread)
Regards
Anton Bassov
hexa
> may get paged if the system is low on memory, so that
> ZwLockVirtualMemory()seems to be more reliable option
Ok, thanks so much for your help.
Z.M.
Slava M. Usov
news:1145686132.1...@u72g2000cwu.googlegroups.com...
You cannot make an entire application non-pageable. However, you can
allocate regions of non-paged memory in an application. Consult PSDK/MSDN
for "Address Windowing Extensions". Basically, you need to call
AllocateUserPhysicalPages() to allocate a number of pages; then call
VirtualAlloc() with the flag MEM_PHYSICAL to reserve a window in your
address space; then call MapUserPhysicalPages() or
MapUserPhysicalPagesScatter() to map the physical pages into the window.
S
anton bassov
I am afraid everything below applies only if the target machine has more
than 4 GB of RAM
>>Consult PSDK/MSDN for "Address Windowing Extensions".
>> Basically, you need to call AllocateUserPhysicalPages() >> to allocate a
number of pages; then call VirtualAlloc() >>with the flag MEM_PHYSICAL to
reserve a window in your
>>address space; then call MapUserPhysicalPages() or
>>MapUserPhysicalPagesScatter() to map the physical pages >>into the window.
Regards
Anton Bassov
Slava M. Usov
news:a385d776324c48db...@ureader.com...
> Hi Slava
>
> I am afraid everything below applies only if the target machine has more
> than 4 GB of RAM
Your fears are ungrounded.
The only documented restriction is that AWE may be unable to use more than
4G on a 32-bit platform without PAE. This does not impair its ability to
allocate up to 4G of non-paged memory.
S
anton bassov
Apparently, I made some 'ad hoc assumption" here - I don't want to argue any
more about it
Regards
Anton Bassov
anton bassov
Please look at AllocateUserPhysicalPages()' documentation - the statement
below is taken from it
//////////////////
64-bit Windows on Itanium-based systems: Due to the difference in page
sizes, AllocateUserPhysicalPages is not supported for 32-bit applications
/////////////////
MapUserPhysicalPages() and MapUserPhysicalPagesScatter()documentation makes
similar statements. Apparently, some more "ad hoc assumptions" by MSDN
Regards
Anton Bassov
Slava M. Usov
Begin transmission.
M. O. R. E. Blank. F. A. U. L. T. Y. Blank. L. O. G. I. C. Period.
End transmission.
I wonder whether I should request my correspondent to acknowledge the
reception of this message, apparently it is not getting through.
You originally "were afraid" that AWE required more than 4G of RAM.
This quotation means "a 32-bit application running on 64-bit Itanium systems
cannot use AWE".
S
anton bassov
This quotation means that there is more than one documented restriction of
AWE (although it is totally unrelated to the original question - I don't
argue about that). You said that the ONLY documented restriction of AWE is
its unability to utilize more than 4 GB of RAM without PAE enabled.
Therefore, I just pointed you to one more documented restriction.
Concerning the original question, let me investigate it a bit (if I am wrong,
I am going to admit it again - don't worry about that)
Regards
Anton Bassov
Slava M. Usov
> Hi Slava
>
> This quotation means that there is more than one documented restriction of
> AWE (although it is totally unrelated to the original question - I don't
> argue about that). You said that the ONLY documented restriction of AWE
> is its unability to utilize more than 4 GB of RAM without PAE enabled.
How very smart. First you set a context for the discussion, namely the RAM
size, then you point out that my statement does not hold in a totally
different context. What a wonderful method to keep arguing just for the sake
of arguing: if I try and say "the only documented restriction concerning the
RAM size....", you will smartly retort by saying, for example, "AWE was not
supported on Windows NT 3.1", or "AWE allocation will usually fail when SQL
Server runs in the AWE mode on the same machine", et cetera, et cetera.
S
anton bassov
Actually, you were right here(I ran the test - it all worked). As you can
see, I am able to admit my mistakes.
However,we still have to sort it out with Cache Manager....
Regards
Anton Bassov
Sam Hobbs
asking for help with the (fundamental) problem.
Here, the solution is to fix pages to prevent them from being swapped to the
page file. The real problem is to protect sensitive data, especially the
password.
If you want help with the fundamental problem, then the problem becomes a
security issue that will get a better answer in the security newsgroup. I am
nearly certain that security specialists will say that the solution of
locking memory is a bad one, but I am not a security specialist. If you ask
in security newsgroup how to develop a tool for better privacy online and
offline then the solution, or one of the most suggested solutions, will be
to use a methodology that uses a hash such that you don't load the password
into memory at all when validating it. That is how Windows (2000 and above
or something like that) and SQL Server authentication work.
"hexa" <he...@email.it> wrote in message
news:1145686132.1...@u72g2000cwu.googlegroups.com...