About inverted calls

NTFSD
1

Hi, all

Seeing the questions about how to make a communications
from a driver to an user mode app, a question comes
upon my mind:

Shouldn’t Microsoft uncover the LPC and make it documented ?
This mechanism is exactly what these developers need,
is compatible across all versions of NT from 4.0 to
current beta version of Longhorn.

We use it in our filter, once we made it work,
the code remains untouched for years and keeps
working.

Yes, the undocumented things can change without
any notification from MS, but would it be the first
time when driver writers have to use an undocumented stuff ?

Or, question to Tony Mason or someone else from OSR:
Couldn’t be an article in The NT Insider about how to connect
two threads through LPC ?
I know that in The NT Insider are no articles about
undocumented things, but …

L.

2

I guess the question is what benefits does it have over the many documented
ways people have been doing it till now? Seriously, I have found Microsoft
will listen to arguments for documenting something, if a good argument can
be presented as to why this is needed. I’ve never played with Windows
LPC’s, so please if there is a good reason they are better than other
mechanisms please share it.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting

“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
> Hi, all
>
> Seeing the questions about how to make a communications
> from a driver to an user mode app, a question comes
> upon my mind:
>
> Shouldn’t Microsoft uncover the LPC and make it documented ?
> This mechanism is exactly what these developers need,
> is compatible across all versions of NT from 4.0 to
> current beta version of Longhorn.
>
> We use it in our filter, once we made it work,
> the code remains untouched for years and keeps
> working.
>
> Yes, the undocumented things can change without
> any notification from MS, but would it be the first
> time when driver writers have to use an undocumented stuff ?
>
> Or, question to Tony Mason or someone else from OSR:
> Couldn’t be an article in The NT Insider about how to connect
> two threads through LPC ?
> I know that in The NT Insider are no articles about
> undocumented things, but …
>
> L.
>
>

3

> be presented as to why this is needed. I’ve never played with Windows

LPC’s, so please if there is a good reason they are better than other
mechanisms please share it.

Maybe I will write an example and put it to the web.
But if you will Google a while, you can find many examples,
like http://www.windowsitlibrary.com/Content/356/08/3.html
(which seems to be quite well written)
I cannot say where the LPC is better or worse than
other methods.

An advantage of LPC here is that is is intended to be used for sharing
informations between two threads, regardless of the process,
regardless of the mode (kernel or user). It is based on
creating LPC port (NtCreatePort), which allows any client to
connect to this port (NtConnectPort). The mechanism allows
waiting for connection, so the user mode application may
wait for connection request from the driver.

I can see one issue with Max’s suggestion,
which may or must not be a problem.
If the user mode application sends an IOCTL which is blocked
by the driver until the driver needs something,
the thread is blocked and cannot be terminated
(even with brutal methods like TerminateThread),
is it right ? AFAIK when a thread runs in kernel mode,
it cannot be terminated (and thus, the owner process
cannot be killed).

L.

4

Actually it can be terminated depending on how the thread is waiting. Also,
note the stock way to do this is OVERLAPPED I/O which puts the thread back
in user space, so this works fine.

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

“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
> I can see one issue with Max’s suggestion,
> which may or must not be a problem.
> If the user mode application sends an IOCTL which is blocked
> by the driver until the driver needs something,
> the thread is blocked and cannot be terminated
> (even with brutal methods like TerminateThread),
> is it right ? AFAIK when a thread runs in kernel mode,
> it cannot be terminated (and thus, the owner process
> cannot be killed).

5

Some of the LPC routines are now exposed in the IFS Kit - for example,
the function ZwConnectPort is in ntifs.h. While not all LPC functions
have been added, certainly several have been. That further suggests if
there is a compelling reason to do so, the additional functions can be
added.

A disadvantage of LPC is that the messages are all small and limited in
size - it is not a good mechanism for transferring large blocks of data.

Given that there are numerous other ways of achieving this without
resorting to undocumented APIs, I wouldn’t find this a compelling
argument for documenting LPCs.

Why not use named pipes instead? They ALSO work between processes and
threads, include security, etc. They are also documented and supported
from kernel mode for direct open (see IoCreateFile for example). Or
shared memory (via section objects)? Again, documented, can be secured,
and has many of the same advantages.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
Sent: Tuesday, November 23, 2004 5:46 AM
To: ntfsd redirect
Subject: Re: Re:[ntfsd] About inverted calls

be presented as to why this is needed. I’ve never played with Windows
LPC’s, so please if there is a good reason they are better than other
mechanisms please share it.

Maybe I will write an example and put it to the web.
But if you will Google a while, you can find many examples,
like http://www.windowsitlibrary.com/Content/356/08/3.html
(which seems to be quite well written)
I cannot say where the LPC is better or worse than
other methods.

An advantage of LPC here is that is is intended to be used for sharing
informations between two threads, regardless of the process,
regardless of the mode (kernel or user). It is based on
creating LPC port (NtCreatePort), which allows any client to
connect to this port (NtConnectPort). The mechanism allows
waiting for connection, so the user mode application may
wait for connection request from the driver.

I can see one issue with Max’s suggestion,
which may or must not be a problem.
If the user mode application sends an IOCTL which is blocked
by the driver until the driver needs something,
the thread is blocked and cannot be terminated
(even with brutal methods like TerminateThread),
is it right ? AFAIK when a thread runs in kernel mode,
it cannot be terminated (and thus, the owner process
cannot be killed).

L.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

> A disadvantage of LPC is that the messages are all small and limited in

size - it is not a good mechanism for transferring large blocks of data.

This is not true. LPC allows to send a section handle
“to the other side”, where you can store any amount of data
you will ever need. The only overhead with this is that you need to
convert the handle between processes.

Why not use named pipes instead? They ALSO work between processes and
threads, include security, etc.

Note that LPC uses security too.
No reason why not to use pipes, maybe they are better
for this. I don’t have any experience with them, can they
be used to transfer from kernel mode to user mode ?

Well, maybe Don Burn is right, LPC would bring nothing
better comparing to currently used (and documented ways)
how to do things.

But anyway, it would be a nice article at OSR Online
(or anywhere else) with description about communicating
driver with user mode , I think people often need help
with this problem (at least here in NTFSD)

L.

7

One more note to this thread:

An advantage of LPC over another methods
may be the fact that it contains the functionalty
of “Send request and wait for reply”.

I think if someone uses the other mentioned methods,
(s)he must implement its own mechanism for
ability to wait for a response from “the other side”.
Correct me if I am wrong.

L.

8

> is it right ? AFAIK when a thread runs in kernel mode,

it cannot be terminated (and thus, the owner process

Correct. Support IRP cancellation properly to relax this issue.

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

9

It is time for another shameless plug for the filter manager.

The filter manager comes with a set of communication libraries for
communicating between user mode and kernel mode. It uses the simple
“send request/wait for reply” model but underneath it is implemented
using and inverted call model.

It properly handles the unexpected termination of the user mode
application as well as the minifilter being unloaded. It also has a
security model where the minifilter defines what ACLs are necessary to
access the communication channel.

Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
Sent: Tuesday, November 23, 2004 11:05 PM
To: Windows File Systems Devs Interest List
Subject: Re: Re:[ntfsd] About inverted calls

One more note to this thread:

An advantage of LPC over another methods
may be the fact that it contains the functionalty
of “Send request and wait for reply”.

I think if someone uses the other mentioned methods,
(s)he must implement its own mechanism for
ability to wait for a response from “the other side”.
Correct me if I am wrong.

L.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com