I’ve been using a driver (NT4) for years that maps system space to user
space with the so-called Section Object Method. Create system space with
MmAllocateContiguousMemory(), and provide virtual addressing to user space
with ZwMapViewOfSection(). Works great. Until 2000 and XP that is.
No matter what I do, the ZwMapViewOfSection() returns an error. Reading
through this ntdev area, I gleaned some info about this problem. I have
since reconstructed the system to use the so-called MDL method. System
space is still created with MmAllocateContiguousMemory(). Then an MDL is
allocated and built with IoAllocateMdl()- MmBuildMdlForNonPagedPool(). A
virtual address is then obtained with a call to MmMapLockedPages(mdl,
UserMode) and MmGetByteOffset(mdl). Works great. That is until the
process is terminated.
I haven’t yet proven that the problem is NOT calling
MmUnmapLockedPages(user_addr, mdl). I will of course write the code to
accomplish this during a controlled shutdown. The problem I have is that
if I force terminate the process (task manager style), the machine BSODS.
It’s as though some kernal corruption occurs when a process which has
nothing more than a virtual address to system space terminates. This all
occurs while testing this ‘new’ method in NT4.
Any help out there??? Thanks in advance. Doug Slowik
This article explains all. You must unlock the pages before terminating
the process.
http://www.osronline.com/article.cfm?id=39
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doug Slowik
Sent: Thursday, June 12, 2003 2:07 PM
To: NT Developers Interest List
Subject: [ntdev] Mapping system memory to user space
I’ve been using a driver (NT4) for years that maps system
space to user space with the so-called Section Object Method.
Create system space with MmAllocateContiguousMemory(), and
provide virtual addressing to user space with
ZwMapViewOfSection(). Works great. Until 2000 and XP that is.
No matter what I do, the ZwMapViewOfSection() returns an
error. Reading through this ntdev area, I gleaned some info
about this problem. I have since reconstructed the system to
use the so-called MDL method. System space is still created
with MmAllocateContiguousMemory(). Then an MDL is allocated
and built with IoAllocateMdl()- MmBuildMdlForNonPagedPool().
A virtual address is then obtained with a call to
MmMapLockedPages(mdl,
UserMode) and MmGetByteOffset(mdl). Works great. That is
until the process is terminated.
I haven’t yet proven that the problem is NOT calling
MmUnmapLockedPages(user_addr, mdl). I will of course write
the code to accomplish this during a controlled shutdown.
The problem I have is that if I force terminate the process
(task manager style), the machine BSODS.
It’s as though some kernal corruption occurs when a process
which has nothing more than a virtual address to system space
terminates. This all occurs while testing this ‘new’ method in NT4.
Any help out there??? Thanks in advance. Doug Slowik
You are currently subscribed to ntdev as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Err, I meant unmap, not unlock the pages.
-----Original Message-----
From: Nick Ryan [mailto:xxxxx@nryan.com]
Sent: Thursday, June 12, 2003 2:20 PM
To: ‘NT Developers Interest List’
Subject: RE: [ntdev] Mapping system memory to user space
This article explains all. You must unlock the pages before
terminating the process.
http://www.osronline.com/article.cfm?id=39
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Doug Slowik
> Sent: Thursday, June 12, 2003 2:07 PM
> To: NT Developers Interest List
> Subject: [ntdev] Mapping system memory to user space
>
>
> I’ve been using a driver (NT4) for years that maps system
> space to user space with the so-called Section Object Method.
> Create system space with MmAllocateContiguousMemory(), and
> provide virtual addressing to user space with
> ZwMapViewOfSection(). Works great. Until 2000 and XP that is.
>
> No matter what I do, the ZwMapViewOfSection() returns an
> error. Reading through this ntdev area, I gleaned some info
> about this problem. I have since reconstructed the system to
> use the so-called MDL method. System space is still created
> with MmAllocateContiguousMemory(). Then an MDL is allocated
> and built with IoAllocateMdl()- MmBuildMdlForNonPagedPool().
> A virtual address is then obtained with a call to
> MmMapLockedPages(mdl,
> UserMode) and MmGetByteOffset(mdl). Works great. That is
> until the process is terminated.
>
> I haven’t yet proven that the problem is NOT calling
> MmUnmapLockedPages(user_addr, mdl). I will of course write
> the code to accomplish this during a controlled shutdown.
> The problem I have is that if I force terminate the process
> (task manager style), the machine BSODS.
> It’s as though some kernal corruption occurs when a process
> which has nothing more than a virtual address to system space
> terminates. This all occurs while testing this ‘new’ method in NT4.
>
> Any help out there??? Thanks in advance. Doug Slowik
>
> —
> You are currently subscribed to ntdev as: xxxxx@nryan.com
> To unsubscribe send a blank email to
xxxxx@lists.osr.com
>
> I haven’t yet proven that the problem is NOT calling
MmUnmapLockedPages(user_addr, mdl). I will of course write the code to
accomplish this during a controlled shutdown. The problem I have is that
if I force terminate the process (task manager style), the machine BSODS.
It’s as though some kernal corruption occurs when a process which has
nothing more than a virtual address to system space terminates. This all
occurs while testing this ‘new’ method in NT4.
If you are asking how to detect that process was terminated - implement
private IOCTL and let application call DeviceIoControl. In your dispatch
function mark IRP pending, setup cancel routine and never complete the IRP.
When process gets terminated your cancel routine will be called - first do
all cleanup that required and then complete the IRP.
Alexei.
Imho more straightforward is to arrange that client process has to keep
device handle (by wich memory mapping was established) open for lifetime of
mapping. Then memory can be unmapped during IRP_MJ_CLEANUP. You may store
additional context information in FsContext field of FileObject member of
the driver’s I/O stack location.
Volker
-----Original Message-----
From: Alexei Jelvis [mailto:xxxxx@rogers.com]
Sent: Friday, June 13, 2003 2:08 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Mapping system memory to user space
> I haven’t yet proven that the problem is NOT calling
> MmUnmapLockedPages(user_addr, mdl). I will of course write
the code to
> accomplish this during a controlled shutdown. The problem
I have is that
> if I force terminate the process (task manager style), the
machine BSODS.
> It’s as though some kernal corruption occurs when a process
which has
> nothing more than a virtual address to system space
terminates. This all
> occurs while testing this ‘new’ method in NT4.
If you are asking how to detect that process was terminated -
implement
private IOCTL and let application call DeviceIoControl. In
your dispatch
function mark IRP pending, setup cancel routine and never
complete the IRP.
When process gets terminated your cancel routine will be
called - first do
all cleanup that required and then complete the IRP.
Alexei.
You are currently subscribed to ntdev as: xxxxx@baslerweb.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
based on some work i’ve been doing recently in the kernel i’m not
entirely sure the system will close handles before it attempts to
destroy the process address space (and thus notice this chunk of memory
that shouldn’t normally be mapped into a user-mode process).
the problem is i’m not sure when the kernel notices this condition,
whether it’s before or after it’s closed the process’s handles.
hopefully someone who has done this will be able to comment on whether
this method works.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Moebius, V.
Sent: Friday, June 13, 2003 1:45 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Mapping system memory to user space
Imho more straightforward is to arrange that client process has to keep
device handle (by wich memory mapping was established) open for lifetime
of mapping. Then memory can be unmapped during IRP_MJ_CLEANUP. You may
store additional context information in FsContext field of FileObject
member of the driver’s I/O stack location.
Volker
-----Original Message-----
From: Alexei Jelvis [mailto:xxxxx@rogers.com]
Sent: Friday, June 13, 2003 2:08 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Mapping system memory to user space
> I haven’t yet proven that the problem is NOT calling
> MmUnmapLockedPages(user_addr, mdl). I will of course write
the code to
> accomplish this during a controlled shutdown. The problem
I have is that
> if I force terminate the process (task manager style), the
machine BSODS.
> It’s as though some kernal corruption occurs when a process
which has
> nothing more than a virtual address to system space
terminates. This all
> occurs while testing this ‘new’ method in NT4.
If you are asking how to detect that process was terminated -
implement private IOCTL and let application call DeviceIoControl. In
your dispatch function mark IRP pending, setup cancel routine and
never complete the IRP.
When process gets terminated your cancel routine will be called -
first do all cleanup that required and then complete the IRP.
Alexei.
You are currently subscribed to ntdev as: xxxxx@baslerweb.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
“Peter Wieland” wrote in message
news:xxxxx@ntdev…
> the problem is i’m not sure when the kernel notices this condition,
> whether it’s before or after it’s closed the process’s handles.
> hopefully someone who has done this will be able to comment on whether
> is method works.
>
Keeping track of the mapping via an open handle, and doing the unmap in
CLEANUP has worked for me.
Note you can NOT defer the unmap to CLOSE (as was implied by an article in
The NT Insider some time ago).
However, there IS a bigger issue involved in mapping kernel memory into user
space, as we’ve discussed on this list (and in The NT Insider) before:
Mapping blocks of kernel memory, such as non-paged pool, can create subtle,
though rare, security problems.
Peter
OSR