FsRtlCreateSectionForDataScan with/out SEC_FILE

Hello,

In the documentation of FsRlt/FltCreateSectionForDataScan there isnt much information regarding SEC_FILE flag. All I can find is “The file specified by the FileObject parameter is a mapped file.” → Can this function be used for anything other than files? . I dont see any difference with or without the flag - both works. So my question is, what is the flag for and will any lower filter see any difference when I use the flag compared to when its not used?

MmCreateSection (the underlying routine) can be used both for image file mappings and data file mappings. When the SEC_IMAGE is used, an image file mapping is created (This can be done by calling NtCreateSection) the file is treated as a PE file, The kernel parses the PE and initializes SectionObjectPointers.ImageSectionObject.

SEC_FILE is used in order to mark that this file is a data file mapping. But in reality, This flag is useless. That’s because ‘SEC_IMAGE’ is used in order to determine if the mapping is an image mapping, If ‘SEC_IMAGE’ is not used, the mapping is assumed to be a data file mapping.

SEC_IMAGE cannot be used in Flt/FsRtlCreateSectionForDataScan, Only in NtCreateSection/MmCreateSection etc.

So practically speaking, the AllocationAttributes parameter does not do anything in Flt/FsRtlCreateSectionForDataScan. It must be ‘SEC_COMMIT’ or ‘SEC_COMMIT | SEC_FILE’ and both options do the same thing: Create a data file mapping.

will any lower filter see any difference when I use the flag compared to when its not used?

Technically, An FS filter can check whether SEC_FILE is used. Since Windows 11, The kernel passes the ‘AllocationAttributes’ via FS_FILTER_PARAMETERS to the PreAcquireForSectionSynchronization filter callback. (This can be seen in the public symbols) - This is not a documented member so formally and logically there’s no difference between using SEC_FILE and not using SEC_FILE.

2 Likes

Thanks for the info!

I have 1 more question, its related to the previous question. Is there any way to differentiate between an UM CreateFileMappingW and FsRtlCreateSectionForDataScan with PreviousMode set to UM (FsRtlCreateSectionForDataScan in PostCreate) in PreAcquireForSectionSynchronization? I asked my previous question because I was going trough the documentation to find any hint related to how I could differentiate between the two. I was not able to find anything. Everything in PFLT_CALLBACK_DATA seems to be the same for FsRtlCreateSectionForDataScan and CreateFileMappingW.

I’m not aware of any way to differentiate between FsRtlCreateSectionForDataScan and CreateFileMappingW. But, If the I/O is issued in FsPostCreate, It means the user handle is not created yet - you can check for the existence of the FO_HANDLE_CREATED flag in the PreAcquireForSectionSynchronization - If FO_HANDLE_CREATED is clear it means it’s probably coming from kernel mode because the user did not receive the handle yet. Not sure it’s a good practice though.

What are you trying to achieve by doing this?

RequestorMode is UM in both cases?

It should be, because the PreviousMode is not modified when FsRtlCreateSectionForDataScan is invoked

RequestorMode is UM. I was trying to differentiate whether its usermode or KM that has mapped a file. Purely for optimization purposes of my code. But FO_HANDLE_CREATED sounds good for now, thanks for the help.