Is it wise to adapt a COM port communication protocol in a kernel mode
driver?
I want to make a special DLL that would have only one instance like a
service or something.
A normal MFC dll makes a instance from a dll everytime when it’s loaded.
The DLL (or service) should be used to do all monitor communication by
RS232 or by a special driver.
The DLL can be loaded by user mode software and should have only one
instance since the used variables should be shared and the COM port
instance should be the same for all user mode applciations.
Any suggestions?
Regards,
Timothy
In NT and beyond a dll has a single instance of the executable image no matter
how many instances. They are copy on write so a debugger can put breakpoints
in a single instance. The Data areas are separate however. There is a
way to link
a common data area, but I don’t remember the exact syntax. Otherwise a memory
mapped section/file can be made common to all instances and help you
achieve what
you want.
George Blat
At 02:00 PM 9/28/2005, you wrote:
Is it wise to adapt a COM port communication protocol in a kernel mode
driver?
I want to make a special DLL that would have only one instance like a
service or something.
A normal MFC dll makes a instance from a dll everytime when it’s loaded.
The DLL (or service) should be used to do all monitor communication by
RS232 or by a special driver.
The DLL can be loaded by user mode software and should have only one
instance since the used variables should be shared and the COM port
instance should be the same for all user mode applciations.
Any suggestions?
Regards,
Timothy
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@brd.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Here is the example how to create a shared data section
in a user mode app or DLL:
#pragma comment(linker, “/SECTION:shared,RWS”)
#pragma data_seg(“shared”)
// Here go shared variables
int aSharedVar = 0; // It has to be initialized otherwise it would
// go to the BSS section.
#pragma data_seg()
Dmitriy Budko
VMware
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of George Blat
Sent: Wednesday, September 28, 2005 4:33 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] COM port communications with one instance dll
In NT and beyond a dll has a single instance of the executable image no
matter
how many instances. They are copy on write so a debugger can put breakpoints
in a single instance. The Data areas are separate however. There is a
way to link
a common data area, but I don’t remember the exact syntax. Otherwise a memory
mapped section/file can be made common to all instances and help you
achieve what
you want.
George Blat
At 02:00 PM 9/28/2005, you wrote:
Is it wise to adapt a COM port communication protocol in a kernel mode
driver?
I want to make a special DLL that would have only one instance like a
service or something.
A normal MFC dll makes a instance from a dll everytime when it’s loaded.
The DLL (or service) should be used to do all monitor communication by
RS232 or by a special driver.
The DLL can be loaded by user mode software and should have only one
instance since the used variables should be shared and the COM port
instance should be the same for all user mode applciations.
Any suggestions?
Regards,
Timothy
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@brd.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@vmware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
So you want to allow one application using your DLL to be able to attack
and possibly bring down another application that’s using your DLL?
Shared variables across processes aren’t a good idea from a security or
reliability standpoint - it’s far to easy for one app to kill another
that way.
The more secure way to do this is with a service that exposes your API
as RPC calls (or DCOM, or whatever message passing scheme makes you
happy). Since the service process is independent from the clients the
clients are now separated, so there’s no easy way for them to attack
each other. They can attack your service, but the RPC interface reduces
the attack surface greatly (compared to a shared memory window).
Of course this would be slower since you’ve got an extra indirection
from app to service to driver to device. The question is whether the
performance advantage of the shared memory method is more or less
important than the security of the service method.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Timothy Messelis
Sent: Wednesday, September 28, 2005 2:00 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] COM port communications with one instance dll
Is it wise to adapt a COM port communication protocol in a kernel mode
driver?
I want to make a special DLL that would have only one instance like a
service or something.
A normal MFC dll makes a instance from a dll everytime when it’s loaded.
The DLL (or service) should be used to do all monitor communication by
RS232 or by a special driver.
The DLL can be loaded by user mode software and should have only one
instance since the used variables should be shared and the COM port
instance should be the same for all user mode applciations.
Any suggestions?
Regards,
Timothy
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
The speed of the application is not really an issue. Offcourse it’s
handy that teh service would be fast but we only GPIO and serial devices
to connect with TFT’s and plasma screens. I’ll have a look ok RPC and
how to implement this. Is there a sample that is usable from the
Microsoft SDK?
Kind regards,
Timothy
“Peter Wieland” wrote in
news:xxxxx@ntdev:
> So you want to allow one application using your DLL to be able to
> attack and possibly bring down another application that’s using your
> DLL?
>
> Shared variables across processes aren’t a good idea from a security
> or reliability standpoint - it’s far to easy for one app to kill
> another that way.
>
> The more secure way to do this is with a service that exposes your API
> as RPC calls (or DCOM, or whatever message passing scheme makes you
> happy). Since the service process is independent from the clients the
> clients are now separated, so there’s no easy way for them to attack
> each other. They can attack your service, but the RPC interface
> reduces the attack surface greatly (compared to a shared memory
> window).
>
> Of course this would be slower since you’ve got an extra indirection
> from app to service to driver to device. The question is whether the
> performance advantage of the shared memory method is more or less
> important than the security of the service method.
>
> -p>
RPC is an old and well-documented technology. The Microsoft Platform SDK
documents it fairly well. Look up RpcServer* and Rpc* general functions in
the SDK. There are other options today, too, such as .Net Remoting.
This is obviously way off course for NTDEV, but these are well-known
technologies for gluing together user-mode processes.
– arlie
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Timothy Messelis
Sent: Monday, October 10, 2005 4:35 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] COM port communications with one instance dll
The speed of the application is not really an issue. Offcourse it’s handy
that teh service would be fast but we only GPIO and serial devices to
connect with TFT’s and plasma screens. I’ll have a look ok RPC and how to
implement this. Is there a sample that is usable from the Microsoft SDK?
Kind regards,
Timothy
> The speed of the application is not really an issue. Offcourse it’s
handy that teh service would be fast but we only GPIO and serial devices
to connect with TFT’s and plasma screens. I’ll have a look ok RPC and
how to implement this. Is there a sample that is usable from the
Microsoft SDK?
A very handy way is to implement an ActiveX ( ATL ) COM “full control” in a EXE
server. And VS60 has wizards to help you with that. Of course , you will still have to
care about synchronization between the different user programs and the Serial
communication port. Since ActiveX COM is a standard , the COM “methods &
properties” can be called even from VB , HTML , programs written with other
compilers such as Borland ( Delphi )…
Christiaan
P.S. doe de groeten aan Jan Favorel
Kind regards,
Timothy
“Peter Wieland” wrote in
> news:xxxxx@ntdev:
>
> > So you want to allow one application using your DLL to be able to
> > attack and possibly bring down another application that’s using your
> > DLL?
> >
> > Shared variables across processes aren’t a good idea from a security
> > or reliability standpoint - it’s far to easy for one app to kill
> > another that way.
> >
> > The more secure way to do this is with a service that exposes your API
> > as RPC calls (or DCOM, or whatever message passing scheme makes you
> > happy). Since the service process is independent from the clients the
> > clients are now separated, so there’s no easy way for them to attack
> > each other. They can attack your service, but the RPC interface
> > reduces the attack surface greatly (compared to a shared memory
> > window).
> >
> > Of course this would be slower since you’ve got an extra indirection
> > from app to service to driver to device. The question is whether the
> > performance advantage of the shared memory method is more or less
> > important than the security of the service method.
> >
> > -p>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@compaqnet.be
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>