Locking down a com port friendly name - another driver/installer is hijacking my COM name!

NTDEV
1

hi

I have a bug on my plate in which, when installed, theToshiba Bluetooth stack version #3 hijacks 2 of the 4 COM ports my virtual-serial-over-usb driver creates while my virtual com ports are actually in use by an app! (It’s not clear whether the Toshiba code has hard-coded what COM Ports it expects to use - I don’t see anything in their inf file that specifies a COM Port name. I also don’t see anything in there indicating it wants to be part of the Ports class. Note that version #4 of the Toshiba Bluetooth stack version #4 doesn’t repro the problem, but I need to make sure my driver is robust and protects itself as much as possible.))

I am concerned that there is something I need to do (besides what I’ve done) to lock down the COM port friendly name, or if the Toshiba Bluetooth stack is behaving badly.

Here’s what I am currently doing - I think that 2c would be enough to lock down the com port name, but I might be wrong.

  1. bus driver that creates the 4 PDOs creating the represent the COM ports creates the PDOs, specifying that the device name should be auto-generated by specifying FILE_AUTOGENERATED_DEVICE_NAME |FILE_DEVICE_SECURE_OPEN as one of the IoCreateDevice parameters.

  2. The driver that gets loaded for the child PDOs specifies “Class=Ports” so that the OS knows to assign the name of the COM port.
    On the IRP_MN_START_DEVICE, I call a routine that does the following:

a) First, look up the COM port friendly name under HKLM\System\CurrentControlSet\Enum<hardwareid>\DeviceParameters. The name is listed under the PortName value.

b) Create a symbolic link between the link name (\DosDevices\COM#) and the device name (\Device\VirSerN)
where N is the instance number and #is the com port name fetched from b.

c) Under HKLM\Hardware\DeviceMap\SerialComm, create a new entry for the COM Port:
\Device\VirSerN REG_SZ COM#

I would think that having that each of the entries under HKLM\Hardware\DeviceMap\SerialComm would be enough to lock down the COM port (so that other drivers couldn’t use the same names) since this is a system-wide registry key. (It also has an entry for the COM1 standard serial port on PCs).

What checking does the OS do to prevent a driver from hijacking a COM Port already assigned by the OS? Is this checking robust, is there any holes? Is the checking based on registry key entries?

I will look at the same DDK serial driver again and google, but I’m hoping one of you (Doron perhaps?) knows the answer to this already and/or have looked into bugs in this area before. And running regmon might help too.

thanks in advance!!!

2

The kernel itself does absolutely nothing. The ports class installer uses the ComDB to assign names. The comdb uses its own tracking system b/c the SERIALCOMM key is only populated by running drivers and claiming a port number for a driver which is currently not running is just as evil as claiming one for a running driver.

The ports class installer assumes ppl are playing by the rules. It is used to hand out names that it knows are free, its role is not to prevent a malicious device install from taking a port name away from another driver.

There is nothing you can do here. This is a massive chicken and egg problem, esp if they are not installing in the ports class.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of S. Drasnin
Sent: Friday, June 09, 2006 11:18 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Locking down a com port friendly name - another driver/installer is hijacking my COM name!

hi
?
I have a bug on my plate in which, when installed, theToshiba Bluetooth stack version #3 hijacks 2 of the 4 COM ports my virtual-serial-over-usb driver creates while my virtual com ports are actually in use by an app!? (It’s not clear whether the Toshiba code has hard-coded what COM Ports it expects to use - I don’t see anything in their inf file that specifies a COM Port name. I also don’t see anything in there indicating it wants to be part of the Ports class. Note that version #4 of the Toshiba Bluetooth stack version #4 doesn’t repro the problem, but I need to make sure my driver is robust and protects itself as much as possible.))
?
I am concerned that there is something I need to do (besides what I’ve done) to lock down the COM port friendly name, or if the Toshiba Bluetooth stack is behaving badly.
?
?
Here’s what I am currently doing - I think that 2c would be enough to lock down the com port name, but I might be wrong.
?

  1. bus driver that creates the 4 PDOs creating the represent the COM ports creates the PDOs, specifying that the device name should be auto-generated by specifying FILE_AUTOGENERATED_DEVICE_NAME |FILE_DEVICE_SECURE_OPEN as one of the IoCreateDevice parameters.
    ?
  2. The driver that gets loaded for the child PDOs specifies “Class=Ports” so that the OS knows to assign the name of the COM port.
    On the IRP_MN_START_DEVICE, I call a routine?that does the following:
    ?
    a) First, look up the COM port friendly name under HKLM\System\CurrentControlSet\Enum<hardwareid>\DeviceParameters. The name is listed under the PortName value.
    ?
    b) Create a symbolic link between the link name (\DosDevices\COM#) and the device name (\Device\VirSerN)
    ???where N is the instance number and #is the com port name fetched from b.
    ???
    ?
    c) Under HKLM\Hardware\DeviceMap\SerialComm, create a new entry for the COM Port:
    ???\Device\VirSerN???REG_SZ???COM#
    ?
    ?
    I would think that having that each of the entries under HKLM\Hardware\DeviceMap\SerialComm would be enough to lock down the COM port (so that other drivers couldn’t use the same names) since this is a system-wide registry key. (It also has an entry for the COM1 standard serial port on PCs).
    ?
    What checking does the OS do to prevent a driver from hijacking a COM Port already assigned by the OS? Is this checking robust, is there any holes? Is the checking based on registry key entries??
    ?
    I will look at the same DDK serial driver again and google, but I’m hoping one of you (Doron perhaps?) knows the answer to this already and/or have looked into bugs in this area before. And running regmon might help too.
    ?
    thanks in advance!!!
    ?
    ?

    —
    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
3

thank you for the good info!

I found some postings on the web indicating that others also ran into this com port Toshiba bluetooth com port hijacking problem in version 3. Also the release notes for version 4.00.01 indicate what looks like a fix: Added the feature to fix the COM port confliction issue.
(Definitely a embarrassing bug.)

What is the purpose of all those com ports (more than 5!) being taken by the Bluetooth stack? Is there one port each for a specific type of data - so that it is routed based on who reads from a particular com port?

thanks again

----- Original Message -----
From: Doron Holanmailto:xxxxx
To: Windows System Software Devs Interest Listmailto:xxxxx
Sent: June 09, 2006 11:59 AM
Subject: RE: [ntdev] Locking down a com port friendly name - another driver/installer is hijacking my COM name!

The kernel itself does absolutely nothing. The ports class installer uses the ComDB to assign names. The comdb uses its own tracking system b/c the SERIALCOMM key is only populated by running drivers and claiming a port number for a driver which is currently not running is just as evil as claiming one for a running driver.

The ports class installer assumes ppl are playing by the rules. It is used to hand out names that it knows are free, its role is not to prevent a malicious device install from taking a port name away from another driver.

There is nothing you can do here. This is a massive chicken and egg problem, esp if they are not installing in the ports class.

d

________________________________________
From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.com] On Behalf Of S. Drasnin
Sent: Friday, June 09, 2006 11:18 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Locking down a com port friendly name - another driver/installer is hijacking my COM name!

hi

I have a bug on my plate in which, when installed, theToshiba Bluetooth stack version #3 hijacks 2 of the 4 COM ports my virtual-serial-over-usb driver creates while my virtual com ports are actually in use by an app! (It’s not clear whether the Toshiba code has hard-coded what COM Ports it expects to use - I don’t see anything in their inf file that specifies a COM Port name. I also don’t see anything in there indicating it wants to be part of the Ports class. Note that version #4 of the Toshiba Bluetooth stack version #4 doesn’t repro the problem, but I need to make sure my driver is robust and protects itself as much as possible.))

I am concerned that there is something I need to do (besides what I’ve done) to lock down the COM port friendly name, or if the Toshiba Bluetooth stack is behaving badly.

Here’s what I am currently doing - I think that 2c would be enough to lock down the com port name, but I might be wrong.

1) bus driver that creates the 4 PDOs creating the represent the COM ports creates the PDOs, specifying that the device name should be auto-generated by specifying FILE_AUTOGENERATED_DEVICE_NAME |FILE_DEVICE_SECURE_OPEN as one of the IoCreateDevice parameters.

2) The driver that gets loaded for the child PDOs specifies “Class=Ports” so that the OS knows to assign the name of the COM port.
On the IRP_MN_START_DEVICE, I call a routine that does the following:

a) First, look up the COM port friendly name under HKLM\System\CurrentControlSet\Enum<hardwareid>\DeviceParameters. The name is listed under the PortName value.

b) Create a symbolic link between the link name (\DosDevices\COM#) and the device name (\Device\VirSerN)
where N is the instance number and #is the com port name fetched from b.

c) Under HKLM\Hardware\DeviceMap\SerialComm, create a new entry for the COM Port:
\Device\VirSerN REG_SZ COM#

I would think that having that each of the entries under HKLM\Hardware\DeviceMap\SerialComm would be enough to lock down the COM port (so that other drivers couldn’t use the same names) since this is a system-wide registry key. (It also has an entry for the COM1 standard serial port on PCs).

What checking does the OS do to prevent a driver from hijacking a COM Port already assigned by the OS? Is this checking robust, is there any holes? Is the checking based on registry key entries?

I will look at the same DDK serial driver again and google, but I’m hoping one of you (Doron perhaps?) knows the answer to this already and/or have looked into bugs in this area before. And running regmon might help too.

thanks in advance!!!

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256http:

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

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256http:

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

4

Each port is a service+device pair. So if you have 10 devices exposing a com port service, you get 10 virtual com ports

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of S. Drasnin
Sent: Friday, June 09, 2006 3:39 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Locking down a com port friendly name - another driver/installer is hijacking my COM name!

thank you for the good info!
?
I found some postings on the web indicating that others also ran into this com port Toshiba bluetooth com port hijacking problem in version 3. Also the release notes for version 4.00.01 indicate what looks like a fix: Added the feature to fix the COM port confliction issue.
(Definitely a embarrassing bug.)
?
What is the purpose of all those com ports? (more than 5!) being taken by the Bluetooth stack? Is there one port each for a specific type of data?- so that it is routed based on who reads from a particular com port?
?
thanks again
?
?
----- Original Message -----
From: Doron Holan
To: Windows System Software Devs Interest List
Sent: June 09, 2006 11:59 AM
Subject: RE: [ntdev] Locking down a com port friendly name - another driver/installer is hijacking my COM name!

The kernel itself does absolutely nothing.? The ports class installer uses the ComDB to assign names.? The comdb uses its own tracking system b/c the SERIALCOMM key is only populated by running drivers and claiming a port number for a driver which is currently not running is just as evil as claiming one for a running driver.

The ports class installer assumes ppl are playing by the rules.? It is used to hand out names that it knows are free, its role is not to prevent a malicious device install from taking a port name away from another driver.

There is nothing you can do here.? This is a massive chicken and egg problem, esp if they are not installing in the ports class.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of S. Drasnin
Sent: Friday, June 09, 2006 11:18 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Locking down a com port friendly name - another driver/installer is hijacking my COM name!

hi

I have a bug on my plate in which, when installed, theToshiba Bluetooth stack version #3 hijacks 2 of the 4 COM ports my virtual-serial-over-usb driver creates while my virtual com ports are actually in use by an app! (It’s not clear whether the Toshiba code has hard-coded what COM Ports it expects to use - I don’t see anything in their inf file that specifies a COM Port name. I also don’t see anything in there indicating it wants to be part of the Ports class. Note that version #4 of the Toshiba Bluetooth stack version #4 doesn’t repro the problem, but I need to make sure my driver is robust and protects itself as much as possible.))

I am concerned that there is something I need to do (besides what I’ve done) to lock down the COM port friendly name, or if the Toshiba Bluetooth stack is behaving badly.

Here’s what I am currently doing - I think that 2c would be enough to lock down the com port name, but I might be wrong.

  1. bus driver that creates the 4 PDOs creating the represent the COM ports creates the PDOs, specifying that the device name should be auto-generated by specifying FILE_AUTOGENERATED_DEVICE_NAME |FILE_DEVICE_SECURE_OPEN as one of the IoCreateDevice parameters.

  2. The driver that gets loaded for the child PDOs specifies “Class=Ports” so that the OS knows to assign the name of the COM port.
    On the IRP_MN_START_DEVICE, I call a routine that does the following:

a) First, look up the COM port friendly name under HKLM\System\CurrentControlSet\Enum<hardwareid>\DeviceParameters. The name is listed under the PortName value.

b) Create a symbolic link between the link name (\DosDevices\COM#) and the device name (\Device\VirSerN)
where N is the instance number and #is the com port name fetched from b.

c) Under HKLM\Hardware\DeviceMap\SerialComm, create a new entry for the COM Port:
\Device\VirSerN REG_SZ COM#

I would think that having that each of the entries under HKLM\Hardware\DeviceMap\SerialComm would be enough to lock down the COM port (so that other drivers couldn’t use the same names) since this is a system-wide registry key. (It also has an entry for the COM1 standard serial port on PCs).

What checking does the OS do to prevent a driver from hijacking a COM Port already assigned by the OS? Is this checking robust, is there any holes? Is the checking based on registry key entries?

I will look at the same DDK serial driver again and google, but I’m hoping one of you (Doron perhaps?) knows the answer to this already and/or have looked into bugs in this area before. And running regmon might help too.

thanks in advance!!!

—
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

—
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