When does an export driver get loaded? Does it load along with a component linked against its import library, or maybe loading is delayed until the first call? If it’s the first, is there any way to explicitly specify delayed loading?
When required, export drivers are loaded by the loader in order to resolve references in another driver (at load time); they can also be explicitly loaded manually.
As far as I know, there’s nothing like delay loaded dll’s in the kernel, but you can certainly achieve what you wish - demand loading - by not linking against your export drivers import library and then explicitly loading it when required. This, however is fairly error prone, especially when considering unloading, so unless you have a good reason to do this, I would avoid it personally, though it is occasionally very useful.
Good luck,
mm
MM, thanks for help. Well, the problem is that there’s no easy substitute for GetProcAddress() in kernel mode, or I’d use demand loading definitely.
Well, there’s AuxKLibGetImageExportDirectory().
mm
Yeah, that’s something I can’t use in my case: I need it to exist at least in DDK 3790, which is not the case. Seems I’ll have to implement kernel mode GetProcAddress() manually, that’s why I’m sad now.
That ddk is 4 releases old. Why can’t you use a new kit?
d
sent from a phpne with no keynoard
-----Original Message-----
From: xxxxx@yandex.ru
Sent: May 03, 2010 7:53 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Export driver loading time
Yeah, that’s something I can’t use in my case: I need it to exist at least in DDK 3790, which is not the case. Seems I’ll have to implement kernel mode GetProcAddress() manually, that’s why I’m sad now.
—
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
> When does an export driver get loaded? Does it load along with a component linked against its
import library, or maybe loading is delayed until the first call?
This depends on how the client binary is built. In user mode, there can be a DLL load delayed till the first call, in kernel mode - I don’t know.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
> Yeah, that’s something I can’t use in my case: I need it to exist at least in DDK 3790
Throw away this outdated software and use WDK 6001.18002 if you need w2k support, or the latest Win7 WDK if you can afford to drop w2k.
The transition of 3790 to the modern tool, even for a large project, is a matter or recompile (with a set of unit tests, which should be done for any other update, so you can merge moving to WDK and other update, and only test once).
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Thanks for your replies, guys!
Well, I’m going to turn to the latest WDK soon. Anyway, even if I did that now I’m not sure AuxKLibGetImageExportDirectory et al. are available in XP, which I have to support. Anyway, I might look into this closer – if this ‘aux_klib.lib’ is not just an import library for some export driver, I could consider linking it to my driver for XP too.
Maxim, regarding delayed load, yes, that’s the thing – I can’t find similar functionality for kernel mode.
Auxklib works downlevel to XP. Why do you need to delay load? You have IRQL restrictions (must be at passive) and the obvious PE export walking is required. Also, kernel mode does not have loader reference counts which means that if multiple drivers who are using the export try to unload the export driver, the export driver unloads on the first trye, leaving all of the other drivers who have references pointing to unloaded coded (unlike user mode where FreeLibrary just decrements the loader count and only unloads on the last reference).
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yandex.ru
Sent: Monday, May 03, 2010 10:30 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Export driver loading time
Thanks for your replies, guys!
Well, I’m going to turn to the latest WDK soon. Anyway, even if I did that now I’m not sure AuxKLibGetImageExportDirectory et al. are available in XP, which I have to support. Anyway, I might look into this closer – if this ‘aux_klib.lib’ is not just an import library for some export driver, I could consider linking it to my driver for XP too.
Maxim, regarding delayed load, yes, that’s the thing – I can’t find similar functionality for kernel mode.
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
xxxxx@yandex.ru wrote:
Well, I’m going to turn to the latest WDK soon. Anyway, even if I did that now I’m not sure AuxKLibGetImageExportDirectory et al. are available in XP, which I have to support. Anyway, I might look into this closer – if this ‘aux_klib.lib’ is not just an import library for some export driver, I could consider linking it to my driver for XP too.
Maxim, regarding delayed load, yes, that’s the thing – I can’t find similar functionality for kernel mode.
No, it’s not there, because such a need is quite unusual. A driver, for
the most part, should do all of its resource acquisition at startup
time. Once you are up and running, the need to additional resources is
just an opportunity for things to go wrong. What would you do if your
external driver was not available? Do you expect to change the driver
binary on the fly?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>look into this closer – if this ‘aux_klib.lib’ is not just an import library for some export driver
It is not, it is a static library wrapped around some undocumented ZwXxx calls.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Doron, yeah, these are things I have to consider very carefully; that’s why I’m even sadder now than before.
Tim, unavailability of the export driver could be more dangerous in case of immediate (as opposed to delayed) load. Consider a filter encryption driver using different crypto algorithm implementations from several export drivers. If you can’t load one of them, you still can go with others; if you can’t load all of them, you still can handle or at least report things somehow. In case of immediate loading the system will just blow up during the load of the filter driver with no chance of control from your side. All I mean is delayed loading means flexibility, and it could be there for kernel mode as well.
Maxim, thanks.
xxxxx@yandex.ru wrote:
Tim, unavailability of the export driver could be more dangerous in case of immediate (as opposed to delayed) load. Consider a filter encryption driver using different crypto algorithm implementations from several export drivers. If you can’t load one of them, you still can go with others; if you can’t load all of them, you still can handle or at least report things somehow. In case of immediate loading the system will just blow up during the load of the filter driver with no chance of control from your side. All I mean is delayed loading means flexibility, and it could be there for kernel mode as well.
But with flexibility comes exposure. There is a certain benefit to
having the system explode if the system configuration is inconsistent,
rather than continuing on and hoping it will resolve itself later. The
more dynamic loading is supported, the easier it is for an attacker to
substitute a malicious DLL for a good DLL.
Kernel code has a higher bar to meet.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
That is indeed the case sometimes, but personally I think that in practice, you need what you need, and designing around the potential to continue in the absence of X, Y and/or Z rarely pays off overall when all sources of error are factored in, like unloading as already discussed; and at a minimum, by introducing dynamic linking in any form to a driver, you’re exposing yourself to at least all the really choice things that plague user mode dlls.
Another way of saying this is that if you statically link everything, the only thing that you can be missing is everything.
Unless I have no other choice, I’m an avowed static linker, whether in user mode or kernel mode. As best as I can recall, I’ve never once found myself wishing that I had made something a dll instead of a lib. The only thing that I think that I’ve ever personally used manual dynamic linking for in the kernel is in development cases where there’s some layering involved and I don’t want have to unload everything every time I change anything and then reboot (where it’s possible to break things out in a way that facilitates this, of course). For that purpose, it was a god send, but it was also messy and not something that I’d ever send out the door.
There obviously are cases where you need dynamically shared code, in addition to those where you are required to do so, but personally I think that arguments about reduced code size/memory usage are totally preposterous reasons to do so and arguments involving ‘security updates’ are at best narrowly defined. In particular, they fail (IMO) to take into account/value/care that they provide a MUCH easier target that moreover is a single point of failure for everything that uses it. Also, the patches themselves provide very convenient little bundles to analyze, and in practice things like CRT’s that are widely shared are the most targeted as well.
To me, the thing that makes the whole ‘update’ idea problematic is that fundamentally, at least some of the consumers of the updates have never been tested with said updates. Maybe seven years ago, all this reflexive patching would have been considered antithetical to security, but media impression is a legitimately powerful thing with very real consequences, so it is what it is.
mm
Thanks for extensive clarifications, guys.
Do NT developers have dedicated IRC channels by any chance? I’m in EFNet #winprog, but it’s generally for user mode development discussions.
AFAIK AuxKLib is supported back to Win2K (even on Win9x but who cares now).
At one time it was a separate download but I think more recently has been
rolled into the WDK.
You can get it from here:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=1e33
f89f-1eec-46a7-9454-c585c7f1bc72
Good Luck,
Dave Cattley
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yandex.ru
Sent: Monday, May 03, 2010 10:54 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Export driver loading time
Yeah, that’s something I can’t use in my case: I need it to exist at least
in DDK 3790, which is not the case. Seems I’ll have to implement kernel mode
GetProcAddress() manually, that’s why I’m sad now.
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
wrote in message news:xxxxx@ntdev…
…
> Unless I have no other choice, I’m an avowed static linker, whether in
> user mode or kernel mode. As best as I can recall, I’ve never once found
> myself wishing that I had made something a dll instead of a lib.
IMHO static link works best for one-man projects. With a relatively large
team,
you may have to spend much effort to componentize, so that all members
could stay productive. Thus, administration oriented solutions can prevail
over
good engineering and good taste. Been there, seen that 
Is this the OP’s situation?
– pa