use serial port at I/O level

NTDEV
1

Hi,

It is possible to access a standard serial port (COM1) dirrectly from a driver by using I/O port instructions bypassing any serial port driver, and without generating any interrupts?

If we disable the standard serial port driver (from Device Manager) than we shall be able to do all the I/O (send only, for experimental tracing purposes) using OUT on 0x3F8?

We actually tried this without success :expressionless: Any idea how to do this, without interfering with the host system in any way (no interrupts, no other problems)?

thank you very much,

Sandor LUKACS

2

Do you mean take over a serial port for your drivers use, excluding the
serial driver from the hardware? Or do you mean temporarily grabing it
while the serial driver owns it?

The first can be done by claiming the resources for the device, then it is
yours to use. The latter is a total disaster and should be avoided.

ā€“
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdevā€¦
> Hi,
>
> It is possible to access a standard serial port (COM1) dirrectly from a
> driver by using I/O port instructions bypassing any serial port driver,
> and without generating any interrupts?
>
> If we disable the standard serial port driver (from Device Manager) than
> we shall be able to do all the I/O (send only, for experimental tracing
> purposes) using OUT on 0x3F8?
>
> We actually tried this without success :expressionless: Any idea how to do this, without
> interfering with the host system in any way (no interrupts, no other
> problems)?
>
> thank you very much,
>
> Sandor LUKACS
>

3

The ports/device are probably powered down (the serial driver explicitly powers down the port when not in use). Furthermore, there is no guarantee that the hw resources for the port reside at 3f8. Why would you want to take over the serial port from another driver?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@bitdefender.com
Sent: Friday, January 25, 2008 6:19 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] use serial port at I/O level

Hi,

It is possible to access a standard serial port (COM1) dirrectly from a driver by using I/O port instructions bypassing any serial port driver, and without generating any interrupts?

If we disable the standard serial port driver (from Device Manager) than we shall be able to do all the I/O (send only, for experimental tracing purposes) using OUT on 0x3F8?

We actually tried this without success :expressionless: Any idea how to do this, without interfering with the host system in any way (no interrupts, no other problems)?

thank you very much,

Sandor LUKACS

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

4

No this is in the really bad idea category. What are you trying to do that
convinced that this was a solution?

On Jan 25, 2008 9:18 AM, wrote:

> Hi,
>
> It is possible to access a standard serial port (COM1) dirrectly from a
> driver by using I/O port instructions bypassing any serial port driver, and
> without generating any interrupts?
>
> If we disable the standard serial port driver (from Device Manager) than
> we shall be able to do all the I/O (send only, for experimental tracing
> purposes) using OUT on 0x3F8?
>
> We actually tried this without success :expressionless: Any idea how to do this, without
> interfering with the host system in any way (no interrupts, no other
> problems)?
>
> thank you very much,
>
> Sandor LUKACS
>
> ā€”
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

ā€“
Mark Roddy

5

> It is possible to access a standard serial port (COM1) dirrectly from a driver

by using I/O port instructions bypassing any serial port driver, and without
generating any interrupts?

Concerning the first part of your question, the answer is ā€œyesā€, simply because there is nothing that is impossible in the kernel mode. What results you get is already another question. If you want your target machine to be stable, you should not touch the resources that you donā€™t own.
Period. In order to do what you want you have to eject the existing serial port, and reclaim the resources that it owns, effectively providing your own version of a serial port driver.

Concerning the second part, your driver just should not connect interrupt when it starts the device. However, what is the point of doing so??? How do you think you will be communicating with your target device???

Anton Bassov

6

Thank you very-very much for your answers,

What I would really like to do is, to be able to send trace messages through the serial COM1 port, exclusively in an in-lab, experimental scenario (so, this will NOT get into any product). It is CRITICAL for me to avoid any interactions with the rest of the system (no PNP, no interrupts, no other 3rd party or standard driver or any other piece of code from an in-box Vista x64 installation shall touch the serial port and I shall not interrupt / interfere with other standard stuffs - except maybe the fact, that I grab/reserve some I/O port range). All other drivers and the rest of the system shall perform like there was never any COM1 actually present in the system. Because this is solely for tracing and is an experimental in-lab stuff, I would welcome any dirty hack / trick that would allow me to do this in as few lines of code, as possible :-))

(For example, on a plain DOS machine this can be achieved in around 15-20 lines of code, which includes UART initialization plus a SendString() C function. How could I do this quickly on Windows?)

have a nice day,

Sandor LUKACS

7

I think that, as long as this is a research/study project, you can do some advanced hooking. You have to hook the target interrupt in IDT plus all dispatch routines in your target driver. In other words, you have to put the existing driver completely out of play - you are going to be the only one who is in charge of all its resources, and the rest of the system should be made believe that it is the target driver who handles everything.

However, what I must warn you from the very beginning is that it is not about ā€œ20 lines of codeā€ as you may think - it is going to be a pretty large project, so that get ready to deal with interrupts, PnP and all other things that you hope to avoid. After all, NT is not like MS-DOSā€¦

Anton Bassov

8

If he disables the device in device manager, there is no need for hooking or touching the IDT b/c there is no interrupt connected and no driver to hook. If you really want to go down this path, you could either
a) continue to do what you are doing and try to steal the resources. Install a ā€œnullā€ driver which all it does is keep the port powered on. You can write such a driver in KMDF very very quickly. Even better, have this driver export the resources to yoru driver via an IOCTL and pound away on the resources directly.

b) have your driver be the FDO for the serial port FDO. you assume control of the hw resources directly and there is no middle man.

I have seen so many ā€œit is only experimental codeā€ drivers that turned into production drivers w/out modification that I think you should do it right from the beginning and go with b.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Sunday, January 27, 2008 11:52 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] use serial port at I/O level

I think that, as long as this is a research/study project, you can do some advanced hooking. You have to hook the target interrupt in IDT plus all dispatch routines in your target driver. In other words, you have to put the existing driver completely out of play - you are going to be the only one who is in charge of all its resources, and the rest of the system should be made believe that it is the target driver who handles everything.

However, what I must warn you from the very beginning is that it is not about ā€œ20 lines of codeā€ as you may think - it is going to be a pretty large project, so that get ready to deal with interrupts, PnP and all other things that you hope to avoid. After all, NT is not like MS-DOSā€¦

Anton Bassov

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

9

Thank you for your answers Anton and Doron,

Doron Holan wrote:

If he disables the device in device manager, there is no need for hooking or touching the IDT b/c there is no interrupt connected and no driver to hook. If you really want to go down this path, you could either
a) continue to do what you are doing and try to steal the resources. Install a ā€œnullā€ driver which all it does is keep the port powered on. You can write such a driver in KMDF very very quickly. Even better, have this driver export the resources to yoru driver via an IOCTL and pound away on the resources directly.

b) have your driver be the FDO for the serial port FDO. you assume control of the hw resources directly and there is no middle man.

I have seen so many ā€œit is only experimental codeā€ drivers that turned into production drivers w/out modification that I think you should do it right from the beginning and go with b.
One colleague yust found a working solution (standard driver on,
disabling all interrupts from the UART, doing only direct port send char
stuff). This works, at least until smb. else doesnā€™t use the COM1. For
our experiments it is just OK.

Believe me, this has ~ 0.00% to get into any product :slight_smile: We are really
clear about that we ā€œscrew upā€ the system and steal a serial port :wink:

have a nice day,

Sandor LUKACS