You can not load a user mode dll from kernel mode.
----- Original Message -----
From: “Ken Galipeau”
To: “File Systems Developers”
Sent: Wednesday, April 24, 2002 5:47 PM
Subject: [ntfsd] LoadLibrary,GetProcAddress
> How does one dynamically link to a DLL and call a function in it from a
> kernel driver. Win32 has LoadLibrary and GetProcAddress. What are the
> equivalent in a driver?
>
> Thanks,
> Ken
> —
> You are currently subscribed to ntfsd as: ratmil@ec.minbas.cu
> To unsubscribe send a blank email to %%email.unsub%%
Ken,
There is currently no way to dynamically link to a DLL or Driver in
kernel mode. The kenel mode routine MmGetSystemRoutineAddress(), which
was added to Windows 2000, was specifically designed to only make
available routines in the kernel and hal (and not drivers). This is so
the system would not have to worry about drivers having pointers to
function in other drivers that might get unloaded.
Neal Christiansen
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
From: Ken Galipeau [mailto:xxxxx@legato.com]
Sent: Wednesday, April 24, 2002 09:48 AM
To: File Systems Developers
Subject: [ntfsd] LoadLibrary,GetProcAddress
How does one dynamically link to a DLL and call a function in it from a
kernel driver. Win32 has LoadLibrary and GetProcAddress. What are the
equivalent in a driver?
Thanks,
Ken
You are currently subscribed to ntfsd as: xxxxx@Windows.Microsoft.com
To unsubscribe send a blank email to %%email.unsub%%
original message rearranged for clarity
“Ratmil Torres” wrote in message news:xxxxx@ntfsd…
> ----- Original Message -----
> > From: “Ken Galipeau”
> > How does one dynamically link to a DLL and call a function in it from a
> > kernel driver. Win32 has LoadLibrary and GetProcAddress. What are the
> > equivalent in a driver?
>
> You can not load a user mode dll from kernel mode.
Not absolutely true. One way I know for sure, and two I’ve never tested,
but I think work.
1) You can write your own PE file loader, and load DLLs, and EXEs to your
heart’s content. Your loader has to do all the fixup, so you should really
only do this if you provide all the services to the DLL, so the DLL doesn’t
need to call any OS functions directly. Funny thing is, though, you can
actually fix up system calls, too, but that is even uglier than just fixing
up your own private API. I’ve fixed bugs in someone else’s code that did
exactly this inside a SCSI miniport, so I know this one works. The benefit
of this approach is that you only fixup the imports the DLL actually uses.
It also doesn’t require modification of the DLL, as long as the DLL is
already tied to the support API you have provided to it. Downside is if the
DLL uses system calls, it can be really hard to get it right.
2) You can pass an block of import function pointers, and another block of
export function pointers, into the DLL entry point, have the DLL fixup it’s
own import table, then fill in the export table you handed it, and you are
done. I don’t see any reason why this can’t work, but I’ve never tried it.
The only unknown is if it’s possible to fixup your own import table inside
the DLL. If it works, and you completely control both ends, this is the
quickest way there. It’s is the simplest way, because you don’t have to
parse the import and export tables in the DLL, but you have to maintain
complete interface synchronization, so you can’t safely load an older DLL
with a newer version of your driver, or vice versa.
3) You make your DLL a kernel-mode DLL, such as SCSIPORT, using the
EXPORT_DRIVER TARGETTYPE in your SOURCES file. I’ve never tested this one,
either, but I don’t see why it can’t work, either. If SCSIPORT works,
another KM DLL should work, too. Probably lots of gaping undocumented
canyons to fall into here, though. If this can be made to work, it seems
like the most elegant solution.
Phil
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
What exactly would be the point of dynamically loading & calling a DLL
which was written to be run in user-mode, which may or may not
statically link to other user-mode DLLs, when there’s a perfectly
straightforward way to export kernel APIs via a driver?
I’m just trying to find out the motivation, it may help to know what the
purpose is.
Ravi
-----Original Message-----
From: Phil Barila [mailto:xxxxx@Seagate.com]
Sent: Wednesday, April 24, 2002 12:14 PM
To: File Systems Developers
Subject: [ntfsd] Re: LoadLibrary,GetProcAddress
original message rearranged for clarity
“Ratmil Torres” wrote in message
news:xxxxx@ntfsd…
> ----- Original Message -----
> > From: “Ken Galipeau”
> > How does one dynamically link to a DLL and call a function in it
> > from a kernel driver. Win32 has LoadLibrary and GetProcAddress. What
> > are the equivalent in a driver?
>
> You can not load a user mode dll from kernel mode.
Not absolutely true. One way I know for sure, and two I’ve never
tested, but I think work.
1) You can write your own PE file loader, and load DLLs, and EXEs to
your heart’s content. Your loader has to do all the fixup, so you
should really only do this if you provide all the services to the DLL,
so the DLL doesn’t need to call any OS functions directly. Funny thing
is, though, you can actually fix up system calls, too, but that is even
uglier than just fixing up your own private API. I’ve fixed bugs in
someone else’s code that did exactly this inside a SCSI miniport, so I
know this one works. The benefit of this approach is that you only
fixup the imports the DLL actually uses. It also doesn’t require
modification of the DLL, as long as the DLL is already tied to the
support API you have provided to it. Downside is if the DLL uses system
calls, it can be really hard to get it right.
2) You can pass an block of import function pointers, and another block
of export function pointers, into the DLL entry point, have the DLL
fixup it’s own import table, then fill in the export table you handed
it, and you are done. I don’t see any reason why this can’t work, but
I’ve never tried it. The only unknown is if it’s possible to fixup your
own import table inside the DLL. If it works, and you completely
control both ends, this is the quickest way there. It’s is the simplest
way, because you don’t have to parse the import and export tables in the
DLL, but you have to maintain complete interface synchronization, so you
can’t safely load an older DLL with a newer version of your driver, or
vice versa.
3) You make your DLL a kernel-mode DLL, such as SCSIPORT, using the
EXPORT_DRIVER TARGETTYPE in your SOURCES file. I’ve never tested this
one, either, but I don’t see why it can’t work, either. If SCSIPORT
works, another KM DLL should work, too. Probably lots of gaping
undocumented canyons to fall into here, though. If this can be made to
work, it seems like the most elegant solution.
Phil
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
—
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to %%email.unsub%%