K to U mode shared memory through sections

Dear All,

My driver is allocating a range of memory.

This memory can be accessed in the driver from any context, user mode
(ioctls) but also in dpcs (timer any...).

At the stage of my developpment, I shared it with user mode by mapping it in
each user space needed it (in an ioctl). It works very well.

Since I know this is not recommended, I'm planning to migrate using sections
now.

I manged to create a named section in kernel mode and opening and mapping it
in user user mode. This was ok.

What I don't understand is what should I do to write some data through the
section when in the context of a dpc for ex? I can't beleive I should map a
view of the section using the NtCurrentProcess (or PsGetCurrentProcessId).
And even if I should do this, should I ensure the user mode process has
already read the shared memory before unmapping the view of the section and
exiting the dpc....?

Many thanks in advance,

Francois.

Don
Thu Nov 24 11:37:08 CST 2005

This is why for almost all drivers, it is not recomended to allocate in the
kernel and map to user space. Can you invert the model, and create the
buffer in user space and call into the driver with an IOCTL? This has the
advantage that you don't have to worry about when to free or unmap the
memory in your driver, also if the IOCTL is canceled you have a signal to
unmap the memory.

You mention synchronizing with the process reading the data, well that is
the other reason the shared memory techique is discouraged, there is no good
mechansim here, and waiting on user space code in a kernel DPC is not going
to work.

I would recomend you tell the group why you think you need the shared
memory, right now I suspect most of us will say throw it out for a normal
model.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply




"Francois Champs" <FrancoisChamps@discussions.microsoft.com> wrote in
message news:E02ECF24-A866-4821-9E50-4FBC18FD8D35@microsoft.com...
> Dear All,
>
> My driver is allocating a range of memory.
>
> This memory can be accessed in the driver from any context, user mode
> (ioctls) but also in dpcs (timer any...).
>
> At the stage of my developpment, I shared it with user mode by mapping it
> in
> each user space needed it (in an ioctl). It works very well.
>
> Since I know this is not recommended, I'm planning to migrate using
> sections
> now.
>
> I manged to create a named section in kernel mode and opening and mapping
> it
> in user user mode. This was ok.
>
> What I don't understand is what should I do to write some data through the
> section when in the context of a dpc for ex? I can't beleive I should map
> a
> view of the section using the NtCurrentProcess (or PsGetCurrentProcessId).
> And even if I should do this, should I ensure the user mode process has
> already read the shared memory before unmapping the view of the section
> and
> exiting the dpc....?
>
> Many thanks in advance,
>
> Francois.

Maxim
Thu Nov 24 19:01:30 CST 2005

The K-U shared memory must be allocated in user mode, otherwise, you will
have sensitive information leaks exposing the kernel pool control structures to
user.
And, the best way of transferring the descriptor of the user memory to the
kernel is the IRP, usually IOCTL IRP.

So, the user part:
- allocates
- sends the allocated region to the kernel via METHOD_xxx_DIRECT IOCTL
- the IOCTL is pended inside the driver till the driver will done with this
memory

The driver:
- accepts the IOCTL
- calls MmGetSystemAddressForMdlSafe for its MDL
- this is the mapped memory which can be used from any kernel context, DPCs
and ISRs included
- must also support IRP cancellation

That's all. No need to ever deal with the section object.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Francois Champs" <FrancoisChamps@discussions.microsoft.com> wrote in message
news:E02ECF24-A866-4821-9E50-4FBC18FD8D35@microsoft.com...
> Dear All,
>
> My driver is allocating a range of memory.
>
> This memory can be accessed in the driver from any context, user mode
> (ioctls) but also in dpcs (timer any...).
>
> At the stage of my developpment, I shared it with user mode by mapping it in
> each user space needed it (in an ioctl). It works very well.
>
> Since I know this is not recommended, I'm planning to migrate using sections
> now.
>
> I manged to create a named section in kernel mode and opening and mapping it
> in user user mode. This was ok.
>
> What I don't understand is what should I do to write some data through the
> section when in the context of a dpc for ex? I can't beleive I should map a
> view of the section using the NtCurrentProcess (or PsGetCurrentProcessId).
> And even if I should do this, should I ensure the user mode process has
> already read the shared memory before unmapping the view of the section and
> exiting the dpc....?
>
> Many thanks in advance,
>
> Francois.

FrancoisChamps
Fri Nov 25 03:05:03 CST 2005

Dear all,
Thank you for your answers Don and Maxim.
Yes I know that the pending irp solution is the one recommended. I use to
implement it several times before; I find it quite complicated anyway.
The reason why I tried this model is:
My driver is a server for events consumed by several clients at the same
time (multi-client events) and shared mem + shared event better fits this
architecture. Pendings Irps would mean a pending queue for each client and
duplicating the events for each.
Anyway, thank you for your help, I understand sections is not the right
direction.
Have a nice day,
Francois.

Don
Fri Nov 25 07:37:02 CST 2005

Consider using a service in conjunction with the driver. Keep the driver
simple with the IOCTL method, and have the service handle the sharing of the
data. This both uses well established techniques (user mode memory sharing)
and simplifies the kernel work making it easier to be reliable.

--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply




"Francois Champs" <FrancoisChamps@discussions.microsoft.com> wrote in
message news:AF59EA31-74E5-4074-B72A-6373A2CB46B1@microsoft.com...
> Dear all,
> Thank you for your answers Don and Maxim.
> Yes I know that the pending irp solution is the one recommended. I use to
> implement it several times before; I find it quite complicated anyway.
> The reason why I tried this model is:
> My driver is a server for events consumed by several clients at the same
> time (multi-client events) and shared mem + shared event better fits this
> architecture. Pendings Irps would mean a pending queue for each client and
> duplicating the events for each.
> Anyway, thank you for your help, I understand sections is not the right
> direction.
> Have a nice day,
> Francois.

Maxim
Fri Nov 25 07:55:51 CST 2005

> Yes I know that the pending irp solution is the one recommended. I use to
> implement it several times before; I find it quite complicated anyway.

Let's face the reality: it is by far simpler then even writing a code which
will call NtCreateSection :) the amount of code to write is minimal, most of
stuff is already done in the IO manager.

> My driver is a server for events consumed by several clients at the same
> time (multi-client events)

Can you consider using WMI? WMI has exactly such events, but they are not so
good in performance. So, if the performance is not critical - you can use WMI.

>and shared mem + shared event better fits this
> architecture.

No. Shared mem is bad. Period. There is no architectures where "shared mem fits
better", except some very narrow special cases.

The reason is that synchronizing access to shared mem is a major problem,
somebody will write there unsynchronized or mis-interpret the partically
written producer's data.

Adding synchronization to shared mem makes the things more complex then the
pending IOCTLs, and still not reliable - anybody can just forget to apply the
synchronization while accessing the shared mem.

>Pendings Irps would mean a pending queue for each client

No, 1 global queue for all clients.

>and duplicating the events for each.

This is the only way.

With shared mem, you have no trigger to notify the clients that the event
really occured.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com