Passing a Pointer from NTBOOTDD.SYS to Post-Kernel Driver

NTDEV
1

Good day, folks.

I’ve got a SCSI Miniport driver (only depending on SCSIPORT.SYS exports) which properly functions as an NTBOOTDD.SYS (pre-kernel). I’d like to pass some data to a different driver post-kernel, which is not a SCSI Miniport driver but which will take over responsibility for providing the boot disk’s storage adapter.

Where might be a nice place to pass a single pointer from the first driver to the second driver? Or what nice alternative strategies might there be?

Also: Can I count on the memory occupied by NTBOOTDD.SYS to remain untouched for the duration of the booted session, or might it be unloaded and overwritten at some point post-kernel? (Read as: I’d like to pass {a pointer to a static in the first driver} to the second driver.)

Also a minor curiosity: If NTBOOTDD.SYS is a copy of FOO.SYS and FOO.SYS is referenced as a boot driver in the SYSTEM hive, will NTLDR be “smart enough” to avoid loading FOO.SYS from disk, knowing that FOO.SYS is the same as the already-loaded NTBOOTDD.SYS?

The target OS is Windows 200, Windows XP, or Windows Server 2003.

Thanks and have a pleasant day.

2

xxxxx@YRDSB.Edu.On.Ca wrote:

Also a minor curiosity: If NTBOOTDD.SYS is a copy of FOO.SYS and FOO.SYS is referenced as a boot driver in the SYSTEM hive, will NTLDR be “smart enough” to avoid loading FOO.SYS from disk, knowing that FOO.SYS is the same as the already-loaded NTBOOTDD.SYS?

How could it possibly know that?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

I’m not too familiar with PE formats, but was assuming that just loading an initial, small blob of FOO.SYS might be enough to reveal an equivalent identity… Signature or hash or I don’t know. Just enough to avoid loading the_rest of the file from disk. Sorry to confuse!

4

xxxxx@YRDSB.Edu.On.Ca wrote:

I’m not too familiar with PE formats, but was assuming that just loading an initial, small blob of FOO.SYS might be enough to reveal an equivalent identity… Signature or hash or I don’t know. Just enough to avoid loading the_rest of the file from disk. Sorry to confuse!

Nope, that wouldn’t be worth the trouble. Sooner or later, sure as
anything, they’d encounter two different drivers with the same hash, and
then all heck would break loose. Windows uses the driver’s path name to
determine identity.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

5

Comments inline:

“xxxxx@YRDSB.Edu.On.Ca” wrote in
message news:xxxxx@ntdev:

> Good day, folks.
>
> I’ve got a SCSI Miniport driver (only depending on SCSIPORT.SYS exports) which properly functions as an NTBOOTDD.SYS (pre-kernel). I’d like to pass some data to a different driver post-kernel, which is not a SCSI Miniport driver but which will take over responsibility for providing the boot disk’s storage adapter.
>
> Where might be a nice place to pass a single pointer from the first driver to the second driver? Or what nice alternative strategies might there be?

Since you control the drivers, can you grab an area on the boot drive
for your data?
>
> Also: Can I count on the memory occupied by NTBOOTDD.SYS to remain untouched for the duration of the booted session, or might it be unloaded and overwritten at some point post-kernel? (Read as: I’d like to pass {a pointer to a static in the first driver} to the second driver.)

No you cannot be sure that the memory is untouched, IIRC it will be
mapped or not at least.
>
> Also a minor curiosity: If NTBOOTDD.SYS is a copy of FOO.SYS and FOO.SYS is referenced as a boot driver in the SYSTEM hive, will NTLDR be “smart enough” to avoid loading FOO.SYS from disk, knowing that FOO.SYS is the same as the already-loaded NTBOOTDD.SYS?

No it does not know, and does not care it loads a new copy.

> The target OS is Windows 200, Windows XP, or Windows Server 2003.
>
> Thanks and have a pleasant day.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

6

Thanks to both of you for your responses.

Unfortunately, the data I wish to pass will actually be a dependency for the second driver to find the storage adapter, so I do not have a disk to pass the data on. That’s a fine idea, though.

Ugly as anything would be hijacking some bytes in the original IVT and looking at them later. I believe that BIOS services aren’t used by NTLDR when it’s using an NTBOOTDD.SYS. But that’s ugly as anything.

If I can’t trust that NTBOOTDD.SYS will not be overwritten at a post-kernel time, then I actually need to find more space than just for a pointer into NTBOOTDD.SYS. D’oh. I could probably “get away with it,” but it just doesn’t seem Nice.