Getting notified on driver load / stopping a driver from loading

NTDEV
1

I would like my driver to be notified whenever a driver is loaded
(ideally as soon as its DriverEntry is complete), eg something like
IoRegisterPlugPlayNotification, but for a driver rather than a
DeviceInterface.

My ultimate goal is to entirely prevent certain drivers from loading at
all. Under Xen, qemu provides an emulated IDE device, and I have written
Xen drivers to use the PV channel which is much faster - but Windows
thinks the qemu IDE device any my PV device are different underlying
devices, and completely wrecks them when it tries to mount them as such
(replaying or truncating logs on one while the other is mounted etc).

Currently I am solving this by loading various filters which fail the
startdevice on the IDE controller when the PV driver is running (when a
boot.ini entry with /GPLPV is selected), or remove the IDE device from
the PCI enumeration. All of these methods seem a bit dirty, and are a
little awkward.

While it would be simple enough just to remove the IDE driver from the
system entirely once the PV drivers are installed, I want to be able to
select between the drivers at boot time, so I only want them disabled
when the /GPLPV boot.ini entry is selected.

The main sticking point is that this absolutely has to be bulletproof.
If something goes wrong and windows manages to mount both ‘copies’ of
the data, it completely destroys the volume.

All suggestions appreciated!

Thanks

James

2

No such mechanism exists to notify you of driver load/unload or that allows you to apply policy to which drivers load.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Monday, December 08, 2008 9:21 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Getting notified on driver load / stopping a driver from loading

I would like my driver to be notified whenever a driver is loaded
(ideally as soon as its DriverEntry is complete), eg something like
IoRegisterPlugPlayNotification, but for a driver rather than a
DeviceInterface.

My ultimate goal is to entirely prevent certain drivers from loading at
all. Under Xen, qemu provides an emulated IDE device, and I have written
Xen drivers to use the PV channel which is much faster - but Windows
thinks the qemu IDE device any my PV device are different underlying
devices, and completely wrecks them when it tries to mount them as such
(replaying or truncating logs on one while the other is mounted etc).

Currently I am solving this by loading various filters which fail the
startdevice on the IDE controller when the PV driver is running (when a
boot.ini entry with /GPLPV is selected), or remove the IDE device from
the PCI enumeration. All of these methods seem a bit dirty, and are a
little awkward.

While it would be simple enough just to remove the IDE driver from the
system entirely once the PV drivers are installed, I want to be able to
select between the drivers at boot time, so I only want them disabled
when the /GPLPV boot.ini entry is selected.

The main sticking point is that this absolutely has to be bulletproof.
If something goes wrong and windows manages to mount both ‘copies’ of
the data, it completely destroys the volume.

All suggestions appreciated!

Thanks

James

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

3

> My ultimate goal is to entirely prevent certain drivers from

loading at all. Under Xen, qemu provides an emulated IDE
device, and I have written Xen drivers to use the PV channel
which is much faster - but Windows thinks the qemu IDE device
any my PV device are different underlying devices, and
completely wrecks them when it tries to mount them as such
(replaying or truncating logs on one while the other is mounted etc).

It seems like the guest OS isn’t the place to assure this, it seems like the
place to assure this is to make sure the virtual environment doesn’t report
the same target to multiple virtual controllers.

A way you could make this more transparent would probably be to make the PV
driver start before the IDE controller. That way, you could arrange for the
first controller that does an Inquiry command to be the owner of the target,
and the second in line to report no device to the Inquiry.

If you had filter drivers (or bus filters) or anything running in the guest,
somebody might remove/damage those (like a Xen guest damaging virus) and
your safety check would get bypassed. If it was in the outer VM environment,
the guest could be sure it won’t mount the same disk on two controllers,
under any conditions.

Jan

4

> > My ultimate goal is to entirely prevent certain drivers from

> loading at all. Under Xen, qemu provides an emulated IDE
> device, and I have written Xen drivers to use the PV channel
> which is much faster - but Windows thinks the qemu IDE device
> any my PV device are different underlying devices, and
> completely wrecks them when it tries to mount them as such
> (replaying or truncating logs on one while the other is mounted
etc).

It seems like the guest OS isn’t the place to assure this, it seems
like
the place to assure this is to make sure the virtual environment
doesn’t
report the same target to multiple virtual controllers.

That has been considered, but the problem is that the qemu BIOS knows
how to work the emulated IDE controller, but not the PV driver.

A way you could make this more transparent would probably be to make
the
PV
driver start before the IDE controller. That way, you could arrange
for
the
first controller that does an Inquiry command to be the owner of the
target,
and the second in line to report no device to the Inquiry.

The IDE controller is virtual and I have no control over it. The backend
device is either a file or a partition, not a physical device.

If you had filter drivers (or bus filters) or anything running in the
guest,
somebody might remove/damage those (like a Xen guest damaging virus)
and
your safety check would get bypassed. If it was in the outer VM
environment,
the guest could be sure it won’t mount the same disk on two
controllers,
under any conditions.

That’s what I’m worried about. I have some safety checks in place - if
the PV driver starts and detects that the number of enumerated harddisks
isn’t the number that it itself has enumerated it bugchecks (not ideal,
but better than the alternative :slight_smile: Similar checks happen in various
other places.

It’s a pity that there is no way my driver can block certain PCI id’s,
or ‘use’ them so that the ide driver never gets called.

Thanks

James

5

> That’s what I’m worried about. I have some safety checks in place - if

the PV driver starts and detects that the number of enumerated harddisks
isn’t the number that it itself has enumerated it bugchecks (not ideal,
but better than the alternative :slight_smile: Similar checks happen in various
other places.

It’s a pity that there is no way my driver can block certain PCI id’s,
or ‘use’ them so that the ide driver never gets called.

Someone gave me some advice. That’s to let drivers, which service qemu
device, don’t start up automatically if PV driver isntalled on system.
Maybe we can modify those drivers’ ‘starttype’ register entry to do that.

Thanks
Wayne