http://msdn.microsoft.com/en-us/library/windows/hardware/ff563684(v=vs.85).aspx
Section Objects and Views
A section object represents a section of memory that can be shared. A process can use a section object to share parts of its memory address space (memory sections) with other processes. Section objects also provide the mechanism by which a process can map a file into its memory address space.
Each memory section has one or more corresponding views. A view of a section is a part of the section that is actually visible to a process. The act of creating a view for a section is known as mapping a view of the section. Each process that is manipulating the contents of a section has its own view; a process can also have multiple views (to the same or different sections).
This section contains the following topics:
File-Backed and Page-File-Backed Sections
All memory sections are supported ("backed") by disk files that can contain, either temporarily or permanently, the data to be shared. When you create a section, you can identify a specific data file to which the section will be backed. Such sections are called file-backed sections. If you do not identify a backing file, the section is backed by the system's paging file and the section is called a page-file-backed section. The data in file-backed sections can be permanently written to disk. Data in page-file-backed sections is never permanently written to disk.
A file-backed section reflects the contents of an actual file on disk; in other words, it is a memory-mapped file. Any access to memory locations within a given file-backed section corresponds to accesses to locations in the associated file. If a process maps the view as read-only, any data that is read from the view is transparently read from the file. Similarly, if the process maps the view as read/write, any data that is read from the view or written to the view is transparently read from or written to the file. In either case, the view's virtual memory does not use any space in the page files. A file-backed section can also be mapped as copy-on-write. In that case, the view's data is read from the file, but any data written to the view is not written to the file; instead it is discarded after the final view is unmapped and the last handle to the section is closed.
A page-file-backed section is backed by the page files instead of by any explicit file on the disk. Any changes that are made to a page-file-backed section are automatically discarded after the section object is destroyed. Page-file-backed sections can be used as shared memory segments between two processes.
Any section, file-backed or not, can be shared between two processes. The same physical memory address range is mapped to a virtual memory address range within each process (though not necessarily to the same virtual address).
Managing Memory Sections
A driver can create a section object by calling ZwCreateSection, which returns a handle to the section object. Use theFileHandle parameter to specify the backing file, or NULL if the section is not file-backed. Additional handles to the section object can be opened by using ZwOpenSection.
To make the data that belongs to a section object accessible within the current process' address space, a view of the section must be mapped. Drivers can map a view of a section into the current process' address space by using theZwMapViewOfSection routine. The SectionOffset parameter specifies the byte offset where the view begins within the section, and the ViewSize specifies the number of bytes to be mapped.
The Protect parameter specifies the allowed operations on the view. Specify PAGE_READONLY for a read-only view, PAGE_READWRITE for a read/write view, and PAGE_WRITECOPY for a copy-on-write view.
No physical memory is allocated for a view until the virtual memory range is accessed. The first access of the memory range causes a page fault; the system then allocates a page to hold that memory location. If the section is file-backed, the system reads the contents of the file that corresponds to that page and copies it into memory. (Note that unused section objects and views do use some paged and nonpaged pool for bookkeeping purposes.)
After a driver is no longer using a view, it unmaps it by making a call to ZwUnmapViewOfSection. After the driver is no longer using the section object, it closes the section handle with ZwClose. Note that after the view is mapped and no other views are going to be mapped, it is safe to immediately call ZwClose on the section handle; the view (and section object) continue to exist until the view is unmapped. This is the recommended practice because it reduces the risk of the driver failing to close the handle.
Security Issues for Section Objects and Views
Drivers that create sections and views that are not to be shared with user mode must use the following protocol when they are working with sections and views:
-
The driver must use a kernel handle when it is opening a handle to the section object. Drivers can make sure that a handle is a kernel handle by either creating it in the system process, or specifying the OBJ_KERNEL_HANDLE attribute for the handle. For more information, see Object Handles.
-
The view must be mapped only from a system thread. (Otherwise, the view is accessible from the process whose context it is created in.) A driver can make sure that the view is mapped from the system process by using a system worker thread to perform the mapping operation. For more information, see System Worker Threads and Driver Thread Context.
Drivers that share a view with a user-mode process must use the following protocol when they are working with sections and views:
-
The driver, not the user-mode process, must create the section object and map the views.
-
As mentioned earlier, the driver must use a kernel handle when it is opening a handle to the section object. Drivers can make sure that a handle is a kernel handle by either creating it in the system process, or specifying the OBJ_KERNEL_HANDLE attribute for the handle. For more information, see Object Handles.
-
The view is mapped in the thread context of the process that shares the view. A highest-level driver can guarantee the view is mapped in the current process context by performing the mapping operation in a dispatch routine, suchDispatchDeviceControl. Dispatch routines of lower-level drivers run in an arbitrary thread context, and thus cannot safely map a view in a dispatch routine. For more information, see Driver Thread Context.
-
All memory accesses to the view within the driver must be protected by try-except blocks. A malicious user-mode application could unmap the view or change the protection state of the view. Either would cause a system crash unless protected by a try-except block. For more information, see Handling Exceptions.
The driver must also validate the contents of the view as necessary. The driver writer cannot assume that only a trusted user-mode component will have access to the view.
A driver that must share a section object with a user-mode application (that must be able to create its own views) must use the following protocol:
-
The driver, not the user-mode process, must create the section object. Drivers must never use a handle that was passed from user mode.
-
Before passing the handle to user mode, the driver must call ObReferenceObjectByHandle to obtain a reference to the section object. This prevents a malicious application from deleting the section object by closing the handle. The object reference should be stored in the driver's device extension.
-
After the driver is no longer using the section object, it must call ObDereferenceObject to release the object reference.
On systems that run Microsoft Windows Server 2003 with Service Pack 1 (SP1) and later versions, only kernel-mode drivers can open \Device\PhysicalMemory. However, drivers can decide to give a handle to a user application. To prevent security issues, only user applications that the driver trusts should be given access to \Device\PhysicalMemory.
723
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
