Empty fields of DeviceNode leading to Death

[art yerkes]

Is there a reference for which registry keys fill (or are supposed to fill)
which members of DeviceNode?  I ask because I wind up finding all of the
combinations that lead to zeros and have a tough time figuring out which
registry values are needed to make them not be zero.

We have a lot of unchecked string functions on the DeviceNode fields in
io/pnpmgr.c, by the way.  I think i've stumbled on four such places so
far, but I suspect that the whole thing should be hardened together.

In any case it would be nice if someone could post a cheat sheet about
how to create a new device entry the right way, or write the code that
fills the DeviceNode in a more obvious way, so that it's easy to find
and see what fills what.

-- 
Here's a simple experiment. Stand on a train track between two locomotives
which are pushing on you with equal force in opposite directions. You will
exhibit no net motion. None the less, you may soon begin to notice that
something important is happening.
-- Robert Stirniman

[Filip Navara]

art yerkes wrote:

>  Is there a reference for which registry keys fill (or
> are supposed to fill)
> which members of DeviceNode?  I ask because I wind up finding all of the
> combinations that lead to zeros and have a tough time figuring out which
> registry values are needed to make them not be zero.
>   
>  
- Only ServiceName is read from the registry and stored in the device node.
- The rest is queried from the PDO created by bus driver (and possibly 
filtered by higher level drivers).
- Some values are stored in registry and retrieved using 
IoGetDeviceProperty.

>  We have a lot of unchecked string functions on the
> DeviceNode fields in
> io/pnpmgr.c, by the way.  I think i've stumbled on four such places so
> far, but I suspect that the whole thing should be hardened together.
>   
>  
Can you be more specific about this? Which strings? Which places?

>  In any case it would be nice if someone could post a
> cheat sheet about
> how to create a new device entry the right way,
>  
It pretty much depends on the type of driver and the driver itself...

>  or write the code that
> fills the DeviceNode in a more obvious way, so that it's easy to find
> and see what fills what.
>  
That's really hard. The current code (starting from 
IopInvalidateDeviceRelations) does several passes over the device tree 
and in each pass fills one part of the DEVICE_NODE. I can't really think 
about some clearer way...

Regards,
Filip

[art yerkes]

> >  We have a lot
> > of unchecked string functions on the DeviceNode fields in
> > io/pnpmgr.c, by the way.  I think i've stumbled on four such places so
> > far, but I suspect that the whole thing should be hardened together.
> >   
> >  
>  Can you be more specific about this? Which strings? Which places? 
I'm wrong that there are a lot, these are the ones I've been bitten by.
I think they're the only cases in which a wcscat/wcscpy is called on a
possibly empty string.

line 171, DeviceNode->InstancePath.Buffer can be null.
line 1059, DeviceNode->InstancePath.Buffer can be null.

-- 
Here's a simple experiment. Stand on a train track between two locomotives
which are pushing on you with equal force in opposite directions. You will
exhibit no net motion. None the less, you may soon begin to notice that
something important is happening.
-- Robert Stirniman