A experiment code slide follows up:
HANDLE hFile;
DWORD nBytesRead=0;
hFile = CreateFile(TEXT(“E:\wer.txt”),
GENERIC_READ|GENERIC_WRITE , FILE_SHARE_READ,
NULL, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL/*|FILE_FLAG_NO_BUFFERING*/,
NULL);
if (hFile == INVALID_HANDLE_VALUE)
{
MessageBox(NULL,TEXT(“Could not open file.”),0,0);
return ERROR1;
}
DWORD size=GetFileSize(hFile,0);
HANDLE hMapFile;
hMapFile = CreateFileMapping(hFile,NULL,
PAGE_READWRITE,0, size, TEXT(“MyFileMappingObject”));
cout<<(int)GetFileSize(hFile,0)< if(hMapFile == NULL)
{
return ERROR2;
}
char* lpMapping = (char*)MapViewOfFile(hMapFile,
FILE_MAP_READ|FILE_MAP_WRITE, 0, 0, size);
cout<<( int ) *(lpMapping+40)< Sleep(2000);
lpMapping[2]=9; //Track IRP_MJ_WRITE
UnmapViewOfFile(lpMapping);
CloseHandle(hMapFile);
CloseHandle(hFile);
Using FileSpy to track IRP, the result is as follows:
(1)FILE_FLAG_NO_BUFFERING flag in CreateFile is set, IRP_MJ_READ/IRP_MJ_WRITE can be tracked each time you execute the program?
(2)FILE_FLAG_NO_BUFFERING flag in CreateFile is not set,IRP_MJ_READ can not be tracked except the first time you execute the program?but IRP_MJ_WRITE can be tracked(using lazy writter) each time?
using FileMon tools, the practice is similar. My question is:
(1)Why this practice comes up?
(2)Does memory mapped files read operation using cache manager to cache the file data?
if it is ,what is the process in detail ?
Thanks.
StephenLi
> (2)Does memory mapped files read operation using cache manager to cache the file data?
No. They use the same set of physical pages that Cc uses, but the IRPs generated by them are noncached and do not route through Cc.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Thanks for your reply.
But I’m still not sure that whether the flag FILE_FLAG_NO_BUFFERING set or not cause different
IRP tracking result.
Is it possible that memory mapped file I/O will use some module other than Cc to cache file data ?
if not ,what can account for the experiment phenomena?
StephenLi
xxxxx@gmail.com
> Is it possible that memory mapped file I/O will use some module other than Cc to cache file data ?
No. Both mmap implementation and Cc use the same Mm’s section object to cache the data.
Actually, if you mmap the file, it is not important whether the handle was opened cached or noncached.
The experiment seems to be a random artifact, kinda some noise due to subtle timing details or such.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
On 9/10/2010 8:29 AM, xxxxx@gmail.com wrote:
Thanks for your reply.
But I’m still not sure that whether the flag FILE_FLAG_NO_BUFFERING set or not cause different
IRP tracking result.
Is it possible that memory mapped file I/O will use some module other than Cc to cache file data ?
if not ,what can account for the experiment phenomena?
I guess I don’t see the phenomenon you are talking about … One thing
to note, it doesn’t matter what flags you use to open the file when
memory mapped IO comes into play (except for read access I think you
need to create the section). You could, for example, close the open file
handle after you have created the mapping. You can then map a view using
the section handle, independent of how the file handle was opened.
In this case, the IO you will see when you start your test would be
in-page (read) paging operations on the file data coming from memory
manager as it handles the page faults on the empty pages.
Pete
StephenLi
xxxxx@gmail.com
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Thanks.
I have tried the experiment many many times, the FILE_FLAG_NO_BUFFERING set or not did effect
the IRP tracking result.
With the flag set, IRP_MJ_READ was tracked;not set,IRP_MJ_READ was not tracked.
Close file handle immediately after creating mapping,the result was same.
Maybe there are some other reasons…
I am doing a file system filter,whether IRP_MJ_READ can be tracked or not is important to tackle mmap file IO.
StephenLi
So I’m not sure what the question is here, things seem to make sense to me
(or at least they are plausible under some circumstances :))… But here are
some things to look at which might help you continue your investigation.
The cache manager, depending on some factors, performs read-ahead. So if you
disable it, there will be no read-ahead and you will see each individual
IRP_MJ_READ as data is brought into the section.
So for [1] (when you have FILE_FLAG_NO_BUFFERING set) this means “do not use
the cache manager”. So no read-ahead, which means you will see each
IRP_MJ_READ (I’m guessing every time you map a different view?).
For [2] (when there is no FILE_FLAG_NO_BUFFERING) then the cache manager
might read ahead and depending on how you set your file mappings, you might
not see individual IRP_MJ_READs…
Things I would try to investigate this:
- For case [2], try to set FILE_FLAG_RANDOM_ACCESS (this would be case [3]
I guess). This should disable cache manager’s read-ahead and my guess you
will see individual IRP_MJ_READs again…
- The cache manager maps data in the file in chunks of 256k. So when you
have [2], try to map views at offsets that are more than 256k apart, which
should mean the data is not in CC so you should see an IRP_MJ_READ. Please
note that a couple of random reads into the file might disable CC’s
read-ahead logic for this file, so this might alter behavior for subsequent
reads, keep this in mind…
- also look at the sizes of the IRP_MJ_READs and the stack, this will tell
you who’s reading the data…
Hope this helps (also, I hope I’m not wrong but I hope the more
knowledgeable members of the community will correct me if this is the
case…)
Thanks,
Alex.
Alex, Thank you very much, the information you provided is helpful.
Up to now,it is certain that IRPs generated by mmap file IO is noncached and do not route through Cc, but Cc is indeed involved(caching the file data when FILE_FLAG_NO_BUFFERING flag is on in CreateFile…) in read-ahead way(not issue IRP_MJ_READ?) to help complete the mmap file IO operation.
Am I right?
Thanks.
StephenLi
Well, CC needs to know about operations on the streams it caches regardless
of how a specific handle is opened. What I mean by that is that if a stream
is already cached then CC will get involved even when another non-cached
handle for the stream is used. CC tries to guarantee data coherency even for
handles that don’t cache.
Read-ahead however is a per-handle thing (the decision about if and what to
read ahead), but it has a global effect, possibly impacting handles that
don’t do cached IO.
Thanks,
Alex.
On 9/10/2010 12:04 PM, xxxxx@gmail.com wrote:
Alex, Thank you very much, the information you provided is helpful.
Up to now,it is certain that IRPs generated by mmap file IO is noncached and do not route through Cc, but Cc is indeed involved(caching the file data when FILE_FLAG_NO_BUFFERING flag is on in CreateFile…) in read-ahead way(not issue IRP_MJ_READ?) to help complete the mmap file IO operation.
There are other interactions happening if you are seeing IO requests
which are not strictly paging requests when you are performing memory
mapped IO on a file. Maybe Explorer is opening the file? Someone else is
accessing it and causing this to happen as a side effect of your test
application.
If the file is opened, a section created, the file closed and then
memory mapped IO performed on the file, you will only see paging read
irps come in against the file. If you see something else, then there is
some other action occurring which is causing it. The system cache could
already contain the file data, for instance, if you are delay/dynamic
loading your driver.
There is no alternative for paging reads other than IRP_MJ_READ requests.
Pete
Am I right?
Thanks.
StephenLi
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
> I am doing a file system filter,whether IRP_MJ_READ can be tracked or not is important
Why? just filter all reads, regardless of when they occur.
If you do this - then the Cc’s cache and the mmaped files (which use the same physical pages) will see the data post-processed by your filter, which is what you want.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
For Alex.
Thanks, things become clear after your explanation.
StephenLi
For Pete.
Thanks for your reply.
There are other interactions happening if you are seeing IO requests
which are not strictly paging requests when you are performing memory
mapped IO on a file. Maybe Explorer is opening the file? Someone else is
accessing it and causing this to happen as a side effect of your test
application.
I think the IRP_MJ_READ I saw is in-page read IRP(with flag 0x43), and the corresponding process is the one in which I was interested,not Explorer or others.
Thanks.
Stephen Li
For All,
> I am doing a file system filter,whether IRP_MJ_READ can be tracked or not is
important
Why? just filter all reads, regardless of when they occur.
If you do this - then the Cc’s cache and the mmaped files (which use the same
physical pages) will see the data post-processed by your filter, which is what
you want.
I’m doing a encryption/decryption filter. For safety consideration, I want to ensure that the file data in cache is ciphertext; or else, if the cache data is plaintext,I have to purge/clear cache(problem seems to be not thoroughly solved…).
I need to process the following aspects:
For Cache IO,intercept irp with flag 0x900,ignore paging irp(with flag 0x43) caused by cache io.
For Non-Cache User IO, they are disk-oriented operations. not difficult.
For Paging IO, cache io caused irps ignored, but the mmap file IO caused irps have to be intercepted and processed furthur.
But for mmap file IO, the only kind of irp we can intercept is paging irp;in this case, if the file data is cached in Cc (read-ahead), it must be plaintext. So cache purging/clearing operation can not be avoided for safety consideration.
Do you have more advice for tackling mmap file IO?
Thanks,
Stephen Li
> I’m doing a encryption/decryption filter. For safety consideration, I want to ensure that the file data in
cache is ciphertext;
Next to impossible. This means that mmaped files will also be ciphertext, they use the same pages.
or else, if the cache data is plaintext,I have to purge/clear cache
Why? Cached data is protected by file ACLs. Is this not enough?
The only value of encryption is to protect the on-media data, for a case of theft or such. There is no need to encrypt the kernel memory, which is protected by file ACLs, or you can add additional create time security checks in your minifilter.
I need to process the following aspects:
Actually (for a case of cleartext cache), you only need to process all noncached IO, be it paging or non-paging.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Maxim, Thanks.
Can we operate or modify the file ACLs which protect the cache data, or ACLs
are maintained by Cc automatically?
Stephen Li
2010/9/11 Maxim S. Shatskih
> > I’m doing a encryption/decryption filter. For safety consideration, I
> want to ensure that the file data in
> >cache is ciphertext;
>
> Next to impossible. This means that mmaped files will also be ciphertext,
> they use the same pages.
>
> >or else, if the cache data is plaintext,I have to purge/clear cache
>
> Why? Cached data is protected by file ACLs. Is this not enough?
>
> The only value of encryption is to protect the on-media data, for a case of
> theft or such. There is no need to encrypt the kernel memory, which is
> protected by file ACLs, or you can add additional create time security
> checks in your minifilter.
>
> > I need to process the following aspects:
>
> Actually (for a case of cleartext cache), you only need to process all
> noncached IO, be it paging or non-paging.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> Can we operate or modify the file ACLs which protect the cache data, or
ACLs are maintained by Cc automatically?
“Right click on the file in explorer and edit the properties tab.”
What Maxim was saying is that applications do not get access to the cache
unless IoManager gives them access to the file and the IoManager won’t give
them access to the file if the ACLs on it do not allows it.
For safety consideration, I want to ensure that the file data in cache
is ciphertext; or else, if the cache data is plaintext,I have to
purge/clear
cache(problem seems to be not thoroughly solved…).
I think then, that you need to think very clearly about your threat model,
and make the whole thing wider than just the software. As an example, how
are you protecting from people taking photographs of the screen when a user
is accessing the data.
OTOH, there may be a class of applications that you want to allow access to
the encrypted file, but not the unencrypted file. In that case if you are
going to give both applications the same quality of access you are going to
have to support caching for one or both of these views and do all the
(signifiant) work to do both this and achieve cache-coherency.
–
Rod Widdowson
Consulting Partner
Steading System Software LLP
+44 1368 850217 +1 508 915 4790