How can I get multiple applications (different processes) to talk to 1 piece
of hardware?
One approach in user mode is to have a singleton COM object be responsible
for creating a handle to the driver. The first time the singleton COM
object is created, the interface is registered with the global interface
table along with a cookie. i.e.
hr = CoCreateInstance(
CLSID_StdGlobalInterfaceTable, // CLSID of the object
(must link in uuid.lib to get)
NULL, //
object is not being created as part of an aggregate
CLSTCX_INPROC_SERVER,
IID_IGlobalInterfaceTable, // ID of the
interface
(void**)&g_pGIT // Address of
pointer variable that receives the interface pointer
);
hr = g_pGIT->RegisterInterfaceInGlobal(
pITheInterface, // Address of
pointer to newly created singleton COM object
IID_ITheInterface, // The ID of
the interface to be registered
&CommonCookie // Pointer to
cookie that other applications will use
);
Once the interface to the singleton COM object is registered, other
applications can use the cookie to get the interface and then talk to the
hardware through the published methods of the singleton COM object. All
IOCTLS sent to the driver/hardware from the singleton COM object are
serialized.
Since the KMDF driver in question has a queue that serializes all of the
IOCTLs it receives, does anyone have an idea of how to basically make sure
that multiple applications are each sending their IOCTLs to the same driver?
For instance, instead of doing the global interface table as described
above, is there a way to maybe create a handle to the driver such that if a
handle already exists in another process then that handle is returned and a
reference count on the driver is incremented?
-Dave
I would try this:
Return STATUS_SUCCESS in your driver for the first IRP_MJ_CREATE you recieve
and some other status code (STATUS_ALREADY_EXISITS?) for subsequent
IRP_MJ_CREATEs. An error returned from a CreateFile call by a second
application should be enough indication to the application that it should
retry CreateFile with OPEN_EXISTING flag.
-Giri.
On 10/6/06, David Voeller wrote:
>
> How can I get multiple applications (different processes) to talk to 1
> piece
> of hardware?
>
> One approach in user mode is to have a singleton COM object be responsible
> for creating a handle to the driver. The first time the singleton COM
> object is created, the interface is registered with the global interface
> table along with a cookie. i.e.
> hr = CoCreateInstance(
> CLSID_StdGlobalInterfaceTable, // CLSID of the
> object
> (must link in uuid.lib to get)
> NULL, //
> object is not being created as part of an aggregate
> CLSTCX_INPROC_SERVER,
> IID_IGlobalInterfaceTable, // ID of the
> interface
> (void**)&g_pGIT // Address of
> pointer variable that receives the interface pointer
> );
>
> hr = g_pGIT->RegisterInterfaceInGlobal(
> pITheInterface, // Address
> of
> pointer to newly created singleton COM object
> IID_ITheInterface, // The ID of
> the interface to be registered
> &CommonCookie // Pointer to
> cookie that other applications will use
> );
>
> Once the interface to the singleton COM object is registered, other
> applications can use the cookie to get the interface and then talk to the
> hardware through the published methods of the singleton COM object. All
> IOCTLS sent to the driver/hardware from the singleton COM object are
> serialized.
>
>
> Since the KMDF driver in question has a queue that serializes all of the
> IOCTLs it receives, does anyone have an idea of how to basically make sure
> that multiple applications are each sending their IOCTLs to the same
> driver?
> For instance, instead of doing the global interface table as described
> above, is there a way to maybe create a handle to the driver such that if
> a
> handle already exists in another process then that handle is returned and
> a
> reference count on the driver is incremented?
>
> -Dave
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Maybe I’m missing something, but what’s wrong with simply allowing
each application to open its own handle to the device? They might be
different handles, but the requests will all be sent to the same
device provided the same device symolic linke name (or device
interface device path) is used in the CreateFile call.
Beverly
On 10/5/06, David Voeller wrote:
> How can I get multiple applications (different processes) to talk to 1 piece
> of hardware?
>
> One approach in user mode is to have a singleton COM object be responsible
> for creating a handle to the driver. The first time the singleton COM
> object is created, the interface is registered with the global interface
> table along with a cookie. i.e.
> hr = CoCreateInstance(
> CLSID_StdGlobalInterfaceTable, // CLSID of the object
> (must link in uuid.lib to get)
> NULL, //
> object is not being created as part of an aggregate
> CLSTCX_INPROC_SERVER,
> IID_IGlobalInterfaceTable, // ID of the
> interface
> (void**)&g_pGIT // Address of
> pointer variable that receives the interface pointer
> );
>
> hr = g_pGIT->RegisterInterfaceInGlobal(
> pITheInterface, // Address of
> pointer to newly created singleton COM object
> IID_ITheInterface, // The ID of
> the interface to be registered
> &CommonCookie // Pointer to
> cookie that other applications will use
> );
>
> Once the interface to the singleton COM object is registered, other
> applications can use the cookie to get the interface and then talk to the
> hardware through the published methods of the singleton COM object. All
> IOCTLS sent to the driver/hardware from the singleton COM object are
> serialized.
>
>
> Since the KMDF driver in question has a queue that serializes all of the
> IOCTLs it receives, does anyone have an idea of how to basically make sure
> that multiple applications are each sending their IOCTLs to the same driver?
> For instance, instead of doing the global interface table as described
> above, is there a way to maybe create a handle to the driver such that if a
> handle already exists in another process then that handle is returned and a
> reference count on the driver is incremented?
>
> -Dave
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
David Voeller wrote:
How can I get multiple applications (different processes) to talk to 1 piece
of hardware?
Why don’t you just let each process open its own handle? As long as you
have not used WdfDeviceInitSetExclusive, multiple processes can open
handles to a single device instance. The WDF queue will serialize the
requests.
Unless you really need some user-mode monitor to provide some other
processing, this is surely the easiest way.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Presumably he has some state that he wants to manage between the
applications, but doesn’t want to put the management of it into the
driver. Hopefully if that’s the case David’s driver will still distrust
the COM component. Otherwise he leaves himself open to security
attacks.
The common method of doing this is to create a service, have that
service take ownership of all of the instances of your device, and then
expose your higher-level API through some IPC mechanism like RPC or
DCOM. In order to cooperate around the device the apps need to have
some trustable agent to manage the device, and that’s either the driver
or a system service separate from each app.
Having an in-proc manager that attempts to manage state between
processes while running within the process doesn’t sound like a great
idea to me.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Beverly Brown
Sent: Thursday, October 05, 2006 12:39 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Multiple applications and only 1 piece of hardware
Maybe I’m missing something, but what’s wrong with simply allowing
each application to open its own handle to the device? They might be
different handles, but the requests will all be sent to the same
device provided the same device symolic linke name (or device
interface device path) is used in the CreateFile call.
Beverly
On 10/5/06, David Voeller wrote:
> How can I get multiple applications (different processes) to talk to 1
piece
> of hardware?
>
> One approach in user mode is to have a singleton COM object be
responsible
> for creating a handle to the driver. The first time the singleton COM
> object is created, the interface is registered with the global
interface
> table along with a cookie. i.e.
> hr = CoCreateInstance(
> CLSID_StdGlobalInterfaceTable, // CLSID of the
object
> (must link in uuid.lib to get)
> NULL,
//
> object is not being created as part of an aggregate
> CLSTCX_INPROC_SERVER,
> IID_IGlobalInterfaceTable, // ID of the
> interface
> (void**)&g_pGIT //
Address of
> pointer variable that receives the interface pointer
> );
>
> hr = g_pGIT->RegisterInterfaceInGlobal(
> pITheInterface, //
Address of
> pointer to newly created singleton COM object
> IID_ITheInterface, // The ID
of
> the interface to be registered
> &CommonCookie // Pointer to
> cookie that other applications will use
> );
>
> Once the interface to the singleton COM object is registered, other
> applications can use the cookie to get the interface and then talk to
the
> hardware through the published methods of the singleton COM object.
All
> IOCTLS sent to the driver/hardware from the singleton COM object are
> serialized.
>
>
> Since the KMDF driver in question has a queue that serializes all of
the
> IOCTLs it receives, does anyone have an idea of how to basically make
sure
> that multiple applications are each sending their IOCTLs to the same
driver?
> For instance, instead of doing the global interface table as described
> above, is there a way to maybe create a handle to the driver such that
if a
> handle already exists in another process then that handle is returned
and a
> reference count on the driver is incremented?
>
> -Dave
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Hmm…he is talking about COM devices. Aren’t they created with EXLUSIVE
flag? When a second application tries to open the COMX which is already open
, it gets “access denied” error. I never tried duplicating handle of a COM
port though.
On 10/6/06, Beverly Brown wrote:
>
> Maybe I’m missing something, but what’s wrong with simply allowing
> each application to open its own handle to the device? They might be
> different handles, but the requests will all be sent to the same
> device provided the same device symolic linke name (or device
> interface device path) is used in the CreateFile call.
>
> Beverly
>
> On 10/5/06, David Voeller wrote:
> > How can I get multiple applications (different processes) to talk to 1
> piece
> > of hardware?
> >
> > One approach in user mode is to have a singleton COM object be
> responsible
> > for creating a handle to the driver. The first time the singleton COM
> > object is created, the interface is registered with the global interface
> > table along with a cookie. i.e.
> > hr = CoCreateInstance(
> > CLSID_StdGlobalInterfaceTable, // CLSID of the
> object
> > (must link in uuid.lib to get)
> > NULL, //
> > object is not being created as part of an aggregate
> > CLSTCX_INPROC_SERVER,
> > IID_IGlobalInterfaceTable, // ID of the
> > interface
> > (void**)&g_pGIT // Address
> of
> > pointer variable that receives the interface pointer
> > );
> >
> > hr = g_pGIT->RegisterInterfaceInGlobal(
> > pITheInterface, // Address
> of
> > pointer to newly created singleton COM object
> > IID_ITheInterface, // The ID of
> > the interface to be registered
> > &CommonCookie // Pointer to
> > cookie that other applications will use
> > );
> >
> > Once the interface to the singleton COM object is registered, other
> > applications can use the cookie to get the interface and then talk to
> the
> > hardware through the published methods of the singleton COM object. All
> > IOCTLS sent to the driver/hardware from the singleton COM object are
> > serialized.
> >
> >
> > Since the KMDF driver in question has a queue that serializes all of the
> > IOCTLs it receives, does anyone have an idea of how to basically make
> sure
> > that multiple applications are each sending their IOCTLs to the same
> driver?
> > For instance, instead of doing the global interface table as described
> > above, is there a way to maybe create a handle to the driver such that
> if a
> > handle already exists in another process then that handle is returned
> and a
> > reference count on the driver is incremented?
> >
> > -Dave
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
> >
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
giri wrote:
Hmm…he is talking about COM devices.
No, I don’t think so. He is talking about using a user-mode COM
(component object model, as in OLE) object to manage his device, not
about using a COM (as in serial port) device. He said he had a KMDF driver.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Sorry for the delay in answering some of the comments/questions, I had to
leave for a parent/teacher conference.
Yes I was talking about OLE COM objects.
One of the questions I had was if each application opened its own handle to
the KMDF device driver, will only one instance of the driver be created and
reference counted and will the IOCTLs from each application be serialized in
the queue of the one driver instance. It sounds like that is the case.
I like the idea of using a service to take ownership of the instances to the
device driver for security reasons. Thanks for that idea Peter Wieland.
“David Voeller” wrote in message news:xxxxx@ntdev…
> How can I get multiple applications (different processes) to talk to 1
> piece of hardware?
>
> One approach in user mode is to have a singleton COM object be responsible
> for creating a handle to the driver. The first time the singleton COM
> object is created, the interface is registered with the global interface
> table along with a cookie. i.e.
> hr = CoCreateInstance(
> CLSID_StdGlobalInterfaceTable, // CLSID of the
> object (must link in uuid.lib to get)
> NULL, //
> object is not being created as part of an aggregate
> CLSTCX_INPROC_SERVER,
> IID_IGlobalInterfaceTable, // ID of the
> interface
> (void**)&g_pGIT // Address of
> pointer variable that receives the interface pointer
> );
>
> hr = g_pGIT->RegisterInterfaceInGlobal(
> pITheInterface, // Address
> of pointer to newly created singleton COM object
> IID_ITheInterface, // The ID of
> the interface to be registered
> &CommonCookie // Pointer to
> cookie that other applications will use
> );
>
> Once the interface to the singleton COM object is registered, other
> applications can use the cookie to get the interface and then talk to the
> hardware through the published methods of the singleton COM object. All
> IOCTLS sent to the driver/hardware from the singleton COM object are
> serialized.
>
>
> Since the KMDF driver in question has a queue that serializes all of the
> IOCTLs it receives, does anyone have an idea of how to basically make sure
> that multiple applications are each sending their IOCTLs to the same
> driver? For instance, instead of doing the global interface table as
> described above, is there a way to maybe create a handle to the driver
> such that if a handle already exists in another process then that handle
> is returned and a reference count on the driver is incremented?
>
> -Dave
>
>
How about having a dll which contains a single global “HANDLE handle” across
multiple instances of applications using it. We can make one app create it
and all the apps use it.
On 10/6/06, David Voeller wrote:
>
> Sorry for the delay in answering some of the comments/questions, I had to
> leave for a parent/teacher conference.
>
> Yes I was talking about OLE COM objects.
>
> One of the questions I had was if each application opened its own handle
> to
> the KMDF device driver, will only one instance of the driver be created
> and
> reference counted and will the IOCTLs from each application be serialized
> in
> the queue of the one driver instance. It sounds like that is the case.
>
> I like the idea of using a service to take ownership of the instances to
> the
> device driver for security reasons. Thanks for that idea Peter Wieland.
>
> “David Voeller” wrote in message news:xxxxx@ntdev…
> > How can I get multiple applications (different processes) to talk to 1
> > piece of hardware?
> >
> > One approach in user mode is to have a singleton COM object be
> responsible
> > for creating a handle to the driver. The first time the singleton COM
> > object is created, the interface is registered with the global interface
> > table along with a cookie. i.e.
> > hr = CoCreateInstance(
> > CLSID_StdGlobalInterfaceTable, // CLSID of the
> > object (must link in uuid.lib to get)
> > NULL, //
> > object is not being created as part of an aggregate
> > CLSTCX_INPROC_SERVER,
> > IID_IGlobalInterfaceTable, // ID of the
> > interface
> > (void**)&g_pGIT // Address
> of
> > pointer variable that receives the interface pointer
> > );
> >
> > hr = g_pGIT->RegisterInterfaceInGlobal(
> > pITheInterface, // Address
> > of pointer to newly created singleton COM object
> > IID_ITheInterface, // The ID of
> > the interface to be registered
> > &CommonCookie // Pointer to
> > cookie that other applications will use
> > );
> >
> > Once the interface to the singleton COM object is registered, other
> > applications can use the cookie to get the interface and then talk to
> the
> > hardware through the published methods of the singleton COM object. All
> > IOCTLS sent to the driver/hardware from the singleton COM object are
> > serialized.
> >
> >
> > Since the KMDF driver in question has a queue that serializes all of the
> > IOCTLs it receives, does anyone have an idea of how to basically make
> sure
> > that multiple applications are each sending their IOCTLs to the same
> > driver? For instance, instead of doing the global interface table as
> > described above, is there a way to maybe create a handle to the driver
> > such that if a handle already exists in another process then that handle
> > is returned and a reference count on the driver is incremented?
> >
> > -Dave
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
KMDF serializes I/O operations based around queues. So if you have a
single serial queue for your device the I/O from all files will get
serialized through that queue.
Having a service adds complexity and you still need to be sure in your
driver that nothing in user-mode (including your service) can trick you
into doing something bad. So think carefully about whether that’s
simplifying your job or making it harder.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller
Sent: Thursday, October 05, 2006 7:39 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Multiple applications and only 1 piece of hardware
Sorry for the delay in answering some of the comments/questions, I had
to
leave for a parent/teacher conference.
Yes I was talking about OLE COM objects.
One of the questions I had was if each application opened its own handle
to
the KMDF device driver, will only one instance of the driver be created
and
reference counted and will the IOCTLs from each application be
serialized in
the queue of the one driver instance. It sounds like that is the case.
I like the idea of using a service to take ownership of the instances to
the
device driver for security reasons. Thanks for that idea Peter Wieland.
“David Voeller” wrote in message
news:xxxxx@ntdev…
> How can I get multiple applications (different processes) to talk to 1
> piece of hardware?
>
> One approach in user mode is to have a singleton COM object be
responsible
> for creating a handle to the driver. The first time the singleton COM
> object is created, the interface is registered with the global
interface
> table along with a cookie. i.e.
> hr = CoCreateInstance(
> CLSID_StdGlobalInterfaceTable, // CLSID of the
> object (must link in uuid.lib to get)
> NULL,
//
> object is not being created as part of an aggregate
> CLSTCX_INPROC_SERVER,
> IID_IGlobalInterfaceTable, // ID of the
> interface
> (void**)&g_pGIT //
Address of
> pointer variable that receives the interface pointer
> );
>
> hr = g_pGIT->RegisterInterfaceInGlobal(
> pITheInterface, //
Address
> of pointer to newly created singleton COM object
> IID_ITheInterface, // The ID
of
> the interface to be registered
> &CommonCookie // Pointer to
> cookie that other applications will use
> );
>
> Once the interface to the singleton COM object is registered, other
> applications can use the cookie to get the interface and then talk to
the
> hardware through the published methods of the singleton COM object.
All
> IOCTLS sent to the driver/hardware from the singleton COM object are
> serialized.
>
>
> Since the KMDF driver in question has a queue that serializes all of
the
> IOCTLs it receives, does anyone have an idea of how to basically make
sure
> that multiple applications are each sending their IOCTLs to the same
> driver? For instance, instead of doing the global interface table as
> described above, is there a way to maybe create a handle to the driver
> such that if a handle already exists in another process then that
handle
> is returned and a reference count on the driver is incremented?
>
> -Dave
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
“giri” wrote in message news:xxxxx@ntdev…
> How about having a dll which contains a single global “HANDLE handle”
> across
> multiple instances of applications using it. We can make one app create
> it
> and all the apps use it.
>
This is a bad idea from a security point of view as was pointed out earlier
in this discussion. Note, a global in the DLL will not work, it takes a
little bit more to go there, but it is really a poor design.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
giri wrote:
How about having a dll which contains a single global “HANDLE handle”
across multiple instances of applications using it. We can make one
app create it and all the apps use it.
Why?? What’s the point? Besides the issues Don pointed out, this is
just adding unnecessary complexity. It’s a piece of cake to handle
multiple opens in the driver. It’s a much easier solution than a
service or a global DLL.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Driver handling multiple opens is a good idea. I get different handles for
different Apps that issue CREATE on the device. OS will take care of
reference counting. In the other case where I share a handle between
applications, I will have to maintain reference count on the handle and
close the handle when the last app terminates. Thats a over-head, I see.
That aside and coming to some kind of policy implementation between
co-operating applications,
Quoting Peter from his earlier post
Having an in-proc manager that attempts to manage state between
processes while running within the process doesn’t sound like a great
idea to me.
Why isn’t that a dll with a shared section containing the state (including
the unique handle to the device) that has to be managed between the
applications a good idea? If there are Vulnerability implications because of
an erroneous application, how can a Windows Service avoid those? Pls give me
more idea on this.
Thanks,
Giri.
On 10/6/06, Tim Roberts wrote:
>
> giri wrote:
>
> > How about having a dll which contains a single global “HANDLE handle”
> > across multiple instances of applications using it. We can make one
> > app create it and all the apps use it.
>
>
> Why?? What’s the point? Besides the issues Don pointed out, this is
> just adding unnecessary complexity. It’s a piece of cake to handle
> multiple opens in the driver. It’s a much easier solution than a
> service or a global DLL.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
“giri” wrote in message news:xxxxx@ntdev…
> Quoting Peter from his earlier post
>
> Having an in-proc manager that attempts to manage state between
> processes while running within the process doesn’t sound like a great
> idea to me.
>
> Why isn’t that a dll with a shared section containing the state
> (including
> the unique handle to the device) that has to be managed between the
> applications a good idea? If there are Vulnerability implications because
> of
> an erroneous application, how can a Windows Service avoid those? Pls give
> me
> more idea on this.
There is no way to control who can attach to a DLL, so there is no way to
control which applications can opem the device or do a request. Basically,
you have opened the device to any and all users, this is a security hole.
Also, the data you share in the DLL is accessable from all applications, so
a malicious app that attaches to the DLL can attack the other processes by
denying the reliable functionality through the DLL.
With a service the device is locked down hard, since only the system can
access it (since services run as part of the system). Then one of the
many interprocess communication (IPC’s) methods is used from a DLL in your
application to the service. The IPC’s have built in security methods, so
who can ask the service to do something is controlled. The data problem
does not occur since the data on managing the device is kept in the
service, not shared in all application spaces.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply