HalpDispatchInterrupt symbol vs MmGetSystemRoutineAddress

James_Harper · January 4, 2009, 8:25am

As per a previous email about patching the windows kernel, the method I
am copying from uses raw addresses (eg 80a4b1cd) (exact kernel versions
are checked before applying of course). If the kernel is loaded at a
different address though, problems may arise, so I want to come up with
something a little more foolproof.

I ran all the to-be-patched addresses through the debugger and it came
up with symbol+offset values for all of them, and most of the symbols
are retrievable via MmGetSystemRoutineAddress but a few of them are not,
specifically:

HalpDispatchInterrupt
HalpApcInterrupt
HalpInitializeLocalUnit

Taking a stab in the dark, I imagine that the ‘p’ stands for ‘private’,
and that these symbol names only exist because of the debugger symbol
mappings. MmGetSystemRoutineAddress returns NULL for these (and I
believe there is a bug in older versions of Windows where
MmGetSystemRoutineAddress on a bad symbol causes bad things to happen?)

My fallback is to just make these as offsets to an earlier symbol (in
terms of kernel address space) that does map via
MmGetSystemRoutineAddress - any better suggestions?

James

Maxim_S_Shatskih · January 4, 2009, 10:07am

>mappings. MmGetSystemRoutineAddress returns NULL for these (and I

Write your own MmGetSystemRoutineAddress by parsing the PE export tables, it is a couple of screens of code.

To find the load address of the module, use ZwQuerySystemInformation with some subcode, which will return you the list of all modules loaded to the kernel with their addresses.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Cay_Bremer · January 4, 2009, 10:12am

Your assumption is right; MmGetSystemRoutineAddress() can only retrieve
exported functions, not private ones.
Since you’re talking about HAL patching, you’ve already left the blessed
and supported path, but searching for byte patterns instead of relying on
magic offsets might turn out to be more failsafe.

Cay

On Sun, 04 Jan 2009 14:24:30 +0100, James Harper
wrote:
> As per a previous email about patching the windows kernel, the method I
> am copying from uses raw addresses (eg 80a4b1cd) (exact kernel versions
> are checked before applying of course). If the kernel is loaded at a
> different address though, problems may arise, so I want to come up with
> something a little more foolproof.
>
> I ran all the to-be-patched addresses through the debugger and it came
> up with symbol+offset values for all of them, and most of the symbols
> are retrievable via MmGetSystemRoutineAddress but a few of them are not,
> specifically:
>
> HalpDispatchInterrupt
> HalpApcInterrupt
> HalpInitializeLocalUnit
>
> Taking a stab in the dark, I imagine that the ‘p’ stands for ‘private’,
> and that these symbol names only exist because of the debugger symbol
> mappings. MmGetSystemRoutineAddress returns NULL for these (and I
> believe there is a bug in older versions of Windows where
> MmGetSystemRoutineAddress on a bad symbol causes bad things to happen?)
>
> My fallback is to just make these as offsets to an earlier symbol (in
> terms of kernel address space) that does map via
> MmGetSystemRoutineAddress - any better suggestions?
>
> James

Ken_Johnson · January 4, 2009, 1:22pm

I’d use the delta-from-known-kernel-symbol approach if you feel that you must go this route. But you must be careful not to break when someone installs a checked or QFE kernel. This approach is obviously only good for exactly one build of the system, and there may be many floating out there (not to mention pae/up flavors too).

Hal.dll is even worse, as then you’ve also got ACPI vs nonACPI thrown in to the mix, as with other things.

This is not what I’d call a supportable approach for anything more than a quick’n’dirty lab environment; even for downlevel builds, it’s going to suck to maintain.

Is there no way that you can detect writes to the TPR (e.g. generated fault) and then attempt to handle this problem in a generic fashion?

? S

-----Original Message-----
From: James Harper
Sent: Sunday, January 04, 2009 05:24
To: Windows System Software Devs Interest List
Subject: [ntdev] HalpDispatchInterrupt symbol vs MmGetSystemRoutineAddress

As per a previous email about patching the windows kernel, the method I
am copying from uses raw addresses (eg 80a4b1cd) (exact kernel versions
are checked before applying of course). If the kernel is loaded at a
different address though, problems may arise, so I want to come up with
something a little more foolproof.

I ran all the to-be-patched addresses through the debugger and it came
up with symbol+offset values for all of them, and most of the symbols
are retrievable via MmGetSystemRoutineAddress but a few of them are not,
specifically:

HalpDispatchInterrupt
HalpApcInterrupt
HalpInitializeLocalUnit

Taking a stab in the dark, I imagine that the ‘p’ stands for ‘private’,
and that these symbol names only exist because of the debugger symbol
mappings. MmGetSystemRoutineAddress returns NULL for these (and I
believe there is a bug in older versions of Windows where
MmGetSystemRoutineAddress on a bad symbol causes bad things to happen?)

My fallback is to just make these as offsets to an earlier symbol (in
terms of kernel address space) that does map via
MmGetSystemRoutineAddress - any better suggestions?

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

Ken_Johnson · January 4, 2009, 1:25pm

Please consider using the blessed AuxKlib calls instead of going through this approach. There is a .lib provided to make them work on downlevel platforms when the APIs are not native to the kernel.

? S

-----Original Message-----
From: Maxim S. Shatskih
Sent: Sunday, January 04, 2009 07:07
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] HalpDispatchInterrupt symbol vs MmGetSystemRoutineAddress

>mappings. MmGetSystemRoutineAddress returns NULL for these (and I

Write your own MmGetSystemRoutineAddress by parsing the PE export tables, it is a couple of screens of code.

To find the load address of the module, use ZwQuerySystemInformation with some subcode, which will return you the list of all modules loaded to the kernel with their addresses.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

—
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

James_Harper · January 4, 2009, 4:17pm

>

Please consider using the blessed AuxKlib calls instead of going
through
this approach. There is a .lib provided to make them work on
downlevel
platforms when the APIs are not native to the kernel.

I’ve never heard of AuxKlib before and google only gives me 5 links. Do
you have any more info?

This really only is for ‘legacy’ (pre-2003sp2) systems so I’m not that
worried about breaking a few rules to do what I need to do, but if there
is a supported way I’d love to learn what it is.

Thanks

James

Ken_Johnson · January 4, 2009, 4:37pm

For an overview, see: http://msdn.microsoft.com/en-us/library/bb963851(VS.85).aspx

(You probably want AuxKlibQueryModuleInformation; see http://msdn.microsoft.com/en-us/library/bb432185(VS.85).aspx ).

S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Sunday, January 04, 2009 4:17 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] HalpDispatchInterrupt symbol vs MmGetSystemRoutineAddress

Please consider using the blessed AuxKlib calls instead of going
through
this approach. There is a .lib provided to make them work on
downlevel
platforms when the APIs are not native to the kernel.

I’ve never heard of AuxKlib before and google only gives me 5 links. Do
you have any more info?

This really only is for ‘legacy’ (pre-2003sp2) systems so I’m not that
worried about breaking a few rules to do what I need to do, but if there
is a supported way I’d love to learn what it is.

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

Ken_Johnson · January 4, 2009, 4:44pm

Part of the problem with that logic is that there may be extra flavors of kernels running around that you don’t know about. For example, large customers that have requested QFE builds from Microsoft for one-off bug fixes ahead of a service pack.

S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Sunday, January 04, 2009 4:17 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] HalpDispatchInterrupt symbol vs MmGetSystemRoutineAddress

Please consider using the blessed AuxKlib calls instead of going
through
this approach. There is a .lib provided to make them work on
downlevel
platforms when the APIs are not native to the kernel.

I’ve never heard of AuxKlib before and google only gives me 5 links. Do
you have any more info?

This really only is for ‘legacy’ (pre-2003sp2) systems so I’m not that
worried about breaking a few rules to do what I need to do, but if there
is a supported way I’d love to learn what it is.

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

James_Harper · January 4, 2009, 5:01pm

>

Part of the problem with that logic is that there may be extra flavors
of
kernels running around that you don’t know about. For example, large
customers that have requested QFE builds from Microsoft for one-off
bug
fixes ahead of a service pack.

Point taken. This is less likely with a kernel that will be virtualised
under Xen, but still possible, so I should at least be able to detect
it.

Thanks

James

Calvin_Guan-2 · January 4, 2009, 8:31pm

I have never used the auxklib and am not sure if it will return the non-exported function. I like Max’s idea of rolling your own “enhanced” version of MmGetSystemAddress. Finding the RVA of any (exported and private) symbols in a PE image is straightforward. Getting the base address is also trivial as Max pointed out. I personally had done this before. It’s self-contained (good for F6 txtsetup). It will not BSOD on searching some non-existing functions like the native MmGetXxx does.

–
Calvin Guan
Broadcom Corp.
Connecting Everything(r)

----- Original Message ----
From: Skywing
To: Windows System Software Devs Interest List
Sent: Sunday, January 4, 2009 10:25:18 AM
Subject: RE: Re:[ntdev] HalpDispatchInterrupt symbol vs MmGetSystemRoutineAddress

Please consider using the blessed AuxKlib calls instead of going through this approach. There is a .lib provided to make them work on downlevel platforms when the APIs are not native to the kernel.

– S

-----Original Message-----
From: Maxim S. Shatskih
Sent: Sunday, January 04, 2009 07:07
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] HalpDispatchInterrupt symbol vs MmGetSystemRoutineAddress

>mappings. MmGetSystemRoutineAddress returns NULL for these (and I

Write your own MmGetSystemRoutineAddress by parsing the PE export tables, it is a couple of screens of code.

To find the load address of the module, use ZwQuerySystemInformation with some subcode, which will return you the list of all modules loaded to the kernel with their addresses.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

—
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

—
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

Maxim_S_Shatskih · January 4, 2009, 9:43pm

>pointed out. I personally had done this before. It’s self-contained (good for F6 txtsetup).

It is also good for supporting the same binary from NT4 up, since NT4 has no PoStartNextPowerIrp and PoCallDriver, which are mandatory to be called in post-NT4.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

James_Harper · January 4, 2009, 9:59pm

>

I’d use the delta-from-known-kernel-symbol approach if you feel that
you
must go this route. But you must be careful not to break when someone
installs a checked or QFE kernel. This approach is obviously only
good
for exactly one build of the system, and there may be many floating
out
there (not to mention pae/up flavors too).

Actually… there is a failsafe in all of this so the worst that can
happen is that the patch just won’t apply.

What the patch does is to replace mmio TPR-writes (all of these
instructions are 5 bytes long (opcode+data)) with a call to a procedure
that uses the Lock Move CR0 instructions, so it is 5 instructions that
will be replaced. The patch isn’t just blindly installed either, the
instructions are decoded first to verify that it is a TPR write
instruction, and which CPU register is being moved into the TPR so that
the correct patch can be called.

Btw, I have being saying ‘kernel’ and meaning kernel + hal (+ misc other
bits and pieces), but someone recently pointed out that that isn’t
really correct. In windows-land do we not think of the hal as part of
the kernel?

Also, someone made a mention of writing a custom hal, but then someone
else said that this wasn’t done anymore. Is that the final word on that?

Fascinating discussions

Thanks

James

Ken_Johnson · January 5, 2009, 12:35am

The purpose of AuxKlib here would be to replace the undocumented ZwQuerySystemInformation calls.

S

[Resent due to Lyris encoding fail.]

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
Sent: Sunday, January 04, 2009 8:31 PM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] HalpDispatchInterrupt symbol vs MmGetSystemRoutineAddress

I have never used the auxklib and am not sure if it will return the non-exported function. I like Max’s idea of rolling your own “enhanced” version of MmGetSystemAddress. Finding the RVA of any (exported and private) symbols in a PE image is straightforward. Getting the base address is also trivial as Max pointed out. I personally had done this before. It’s self-contained (good for F6 txtsetup). It will not BSOD on searching some non-existing functions like the native MmGetXxx does.

–
Calvin Guan
Broadcom Corp.
Connecting Everything(r)

----- Original Message ----
From: Skywing
To: Windows System Software Devs Interest List
Sent: Sunday, January 4, 2009 10:25:18 AM
Subject: RE: Re:[ntdev] HalpDispatchInterrupt symbol vs MmGetSystemRoutineAddress

Please consider using the blessed AuxKlib calls instead of going through this approach. There is a .lib provided to make them work on downlevel platforms when the APIs are not native to the kernel.

- S

-----Original Message-----
From: Maxim S. Shatskih
Sent: Sunday, January 04, 2009 07:07
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] HalpDispatchInterrupt symbol vs MmGetSystemRoutineAddress

>mappings. MmGetSystemRoutineAddress returns NULL for these (and I

Write your own MmGetSystemRoutineAddress by parsing the PE export tables, it is a couple of screens of code.

To find the load address of the module, use ZwQuerySystemInformation with some subcode, which will return you the list of all modules loaded to the kernel with their addresses.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

—
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

—
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

—
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

Ken_Johnson · January 5, 2009, 12:38am

Well, “kernel” is an ambiguous term. If you’re talking about the kernel binary, that’s ntoskrnl.exe, which is isolated from the hal binary (hal.dll). But for most purposes, however, I’d imagine folks tend to think of them as a single unit.

BTW - if you’re always patching 5 byte instructions on 32-bit mode, can’t you take a more generic approach to this (hot replacing with a call/rel32), if you’re going to trap on the writes, anyway?

S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Sunday, January 04, 2009 9:59 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] HalpDispatchInterrupt symbol vs MmGetSystemRoutineAddress

I’d use the delta-from-known-kernel-symbol approach if you feel that
you
must go this route. But you must be careful not to break when someone
installs a checked or QFE kernel. This approach is obviously only
good
for exactly one build of the system, and there may be many floating
out
there (not to mention pae/up flavors too).

Actually… there is a failsafe in all of this so the worst that can
happen is that the patch just won’t apply.

What the patch does is to replace mmio TPR-writes (all of these
instructions are 5 bytes long (opcode+data)) with a call to a procedure
that uses the Lock Move CR0 instructions, so it is 5 instructions that
will be replaced. The patch isn’t just blindly installed either, the
instructions are decoded first to verify that it is a TPR write
instruction, and which CPU register is being moved into the TPR so that
the correct patch can be called.

Btw, I have being saying ‘kernel’ and meaning kernel + hal (+ misc other
bits and pieces), but someone recently pointed out that that isn’t
really correct. In windows-land do we not think of the hal as part of
the kernel?

Also, someone made a mention of writing a custom hal, but then someone
else said that this wasn’t done anymore. Is that the final word on that?

Fascinating discussions

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

Doron_Holan · January 5, 2009, 2:48am

Auxklib will give the list of loaded modules (AuxKlibQueryModuleInformation) which inclueds the image base. It will also give you the export directory (AuxKlibGetImageExportDirectory). Note that you will have to walk the directory yourself, Auxklib does not provide a replacement for MmGetSystemRoutineAddress nor will it find any functions (at least without symbols) that are private and not exported from the image.

Another note of caution: auxklib does not guarantee that the image whose exports you are searching will stay loaded in memory for the duration of your search. For ntoskrnl or hal.dll this is not a big deal since they will never be unloaded, but for other random images, they can be unloaded as soon as they are reported via AuxKlibQueryModuleInformation. If you want to walk the export directories of these images, you have to make sure the image stays in memory (which will be a custom solution for each image) for the duration of your search.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
Sent: Sunday, January 04, 2009 5:31 PM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] HalpDispatchInterrupt symbol vs MmGetSystemRoutineAddress

I have never used the auxklib and am not sure if it will return the non-exported function. I like Max’s idea of rolling your own “enhanced” version of MmGetSystemAddress. Finding the RVA of any (exported and private) symbols in a PE image is straightforward. Getting the base address is also trivial as Max pointed out. I personally had done this before. It’s self-contained (good for F6 txtsetup). It will not BSOD on searching some non-existing functions like the native MmGetXxx does.

–
Calvin Guan
Broadcom Corp.
Connecting Everything(r)

----- Original Message ----
From: Skywing
To: Windows System Software Devs Interest List
Sent: Sunday, January 4, 2009 10:25:18 AM
Subject: RE: Re:[ntdev] HalpDispatchInterrupt symbol vs MmGetSystemRoutineAddress

Please consider using the blessed AuxKlib calls instead of going through this approach. There is a .lib provided to make them work on downlevel platforms when the APIs are not native to the kernel.

? S

-----Original Message-----
From: Maxim S. Shatskih
Sent: Sunday, January 04, 2009 07:07
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] HalpDispatchInterrupt symbol vs MmGetSystemRoutineAddress

>mappings. MmGetSystemRoutineAddress returns NULL for these (and I

Write your own MmGetSystemRoutineAddress by parsing the PE export tables, it is a couple of screens of code.

To find the load address of the module, use ZwQuerySystemInformation with some subcode, which will return you the list of all modules loaded to the kernel with their addresses.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

—
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

—
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

—
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

James_Harper · January 5, 2009, 4:59am

>

Auxklib will give the list of loaded modules
(AuxKlibQueryModuleInformation) which inclueds the image base. It will
also give you the export directory (AuxKlibGetImageExportDirectory).
Note
that you will have to walk the directory yourself, Auxklib does not
provide a replacement for MmGetSystemRoutineAddress nor will it find
any
functions (at least without symbols) that are private and not exported
from the image.

Another note of caution: auxklib does not guarantee that the image
whose
exports you are searching will stay loaded in memory for the duration
of
your search. For ntoskrnl or hal.dll this is not a big deal since
they
will never be unloaded, but for other random images, they can be
unloaded
as soon as they are reported via AuxKlibQueryModuleInformation. If you
want to walk the export directories of these images, you have to make
sure
the image stays in memory (which will be a custom solution for each
image)
for the duration of your search.

Hmmm… the more I read about those functions the less inclined I am to
want to use them. They don’t even appear to document what IRQL they can
be called at…

In my case though, all the TPR writes are in hal.dll anyway. I wonder
what would be involved in writing a custom hal.dll…

James

Doron_Holan · January 5, 2009, 10:03am

These are passive level apis (as are all Zw* apis), but you only need to do this once on boot no? You have no passive level entry point from within your driver that you can do this? Even if you find the base address some other way, there is guarantee that all parts of the PE header are currently paged in so a higher irql probably will not work reliably anyways.

A custom hal is not possible, the hal kit no longer ships.

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: James Harper
Sent: Monday, January 05, 2009 2:01 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] HalpDispatchInterrupt symbol vs MmGetSystemRoutineAddress

>
> Auxklib will give the list of loaded modules
> (AuxKlibQueryModuleInformation) which inclueds the image base. It will
> also give you the export directory (AuxKlibGetImageExportDirectory).
Note
> that you will have to walk the directory yourself, Auxklib does not
> provide a replacement for MmGetSystemRoutineAddress nor will it find
any
> functions (at least without symbols) that are private and not exported
> from the image.
>
> Another note of caution: auxklib does not guarantee that the image
whose
> exports you are searching will stay loaded in memory for the duration
of
> your search. For ntoskrnl or hal.dll this is not a big deal since
they
> will never be unloaded, but for other random images, they can be
unloaded
> as soon as they are reported via AuxKlibQueryModuleInformation. If you
> want to walk the export directories of these images, you have to make
sure
> the image stays in memory (which will be a custom solution for each
image)
> for the duration of your search.
>

Hmmm… the more I read about those functions the less inclined I am to
want to use them. They don’t even appear to document what IRQL they can
be called at…

In my case though, all the TPR writes are in hal.dll anyway. I wonder
what would be involved in writing a custom hal.dll…

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

Ken_Johnson · January 5, 2009, 10:29am

I believe that they must be called at PASSIVE_LEVEL.

? S

-----Original Message-----
From: James Harper
Sent: Monday, January 05, 2009 01:59
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] HalpDispatchInterrupt symbol vs MmGetSystemRoutineAddress

>
> Auxklib will give the list of loaded modules
> (AuxKlibQueryModuleInformation) which inclueds the image base. It will
> also give you the export directory (AuxKlibGetImageExportDirectory).
Note
> that you will have to walk the directory yourself, Auxklib does not
> provide a replacement for MmGetSystemRoutineAddress nor will it find
any
> functions (at least without symbols) that are private and not exported
> from the image.
>
> Another note of caution: auxklib does not guarantee that the image
whose
> exports you are searching will stay loaded in memory for the duration
of
> your search. For ntoskrnl or hal.dll this is not a big deal since
they
> will never be unloaded, but for other random images, they can be
unloaded
> as soon as they are reported via AuxKlibQueryModuleInformation. If you
> want to walk the export directories of these images, you have to make
sure
> the image stays in memory (which will be a custom solution for each
image)
> for the duration of your search.
>

Hmmm… the more I read about those functions the less inclined I am to
want to use them. They don’t even appear to document what IRQL they can
be called at…

In my case though, all the TPR writes are in hal.dll anyway. I wonder
what would be involved in writing a custom hal.dll…

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

Maxim_S_Shatskih · January 5, 2009, 2:00pm

>really correct. In windows-land do we not think of the hal as part of

the kernel?

Kinda. In Windows, the word “kernel” is often used to denote NTOSKRNL+HAL.

From what I remember, there were only 4 NTOSKRNL binaries for a given CPU kind - SMP/UP, PAE/no-PAE.

Vista and later dropped UP, and also I do not think there is a PAE-less binary for x64 - I think x64 mandates PAE.

So, probably there is only 1 Vista/2008 x64 NTOSKRNL.EXE file.

This means that NTOSKRNL cannot contain any code which talks to hardware other then the CPU-embedded stuff. So, all this code is in HAL.DLL, this is the primary purpose of HAL.

Talking to:

timers
interrupt controllers
IPI hardware (usually in the interrupt controller)
CPU reset (reboot) hardware
hardware implementation of IRQL
is done by HAL routines only, and NTOSKRNL calls them.

Yes, I know that TPR is embedded to CPU, but it is logically part of APIC, so, it is in HALAPIC.DLL’s implementation of KeRaise/LowerIrql.

Jake also told us that in x64 kernel, the APIC is assumed to be embedded to CPU, so KeRaise/LowerIrql are inlined as CR8 accesses.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Ken_Johnson · January 5, 2009, 2:49pm

Of course, many things that used to be the HAL’s domain are moving over towards things like bus drivers, too.

? S

-----Original Message-----
From: Maxim S. Shatskih
Sent: Monday, January 05, 2009 11:00
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] HalpDispatchInterrupt symbol vs MmGetSystemRoutineAddress

>really correct. In windows-land do we not think of the hal as part of
>the kernel?

Kinda. In Windows, the word “kernel” is often used to denote NTOSKRNL+HAL.

From what I remember, there were only 4 NTOSKRNL binaries for a given CPU kind - SMP/UP, PAE/no-PAE.

Vista and later dropped UP, and also I do not think there is a PAE-less binary for x64 - I think x64 mandates PAE.

So, probably there is only 1 Vista/2008 x64 NTOSKRNL.EXE file.

This means that NTOSKRNL cannot contain any code which talks to hardware other then the CPU-embedded stuff. So, all this code is in HAL.DLL, this is the primary purpose of HAL.

Talking to:

- timers
- interrupt controllers
- IPI hardware (usually in the interrupt controller)
- CPU reset (reboot) hardware
- hardware implementation of IRQL

- is done by HAL routines only, and NTOSKRNL calls them.

Yes, I know that TPR is embedded to CPU, but it is logically part of APIC, so, it is in HALAPIC.DLL’s implementation of KeRaise/LowerIrql.

Jake also told us that in x64 kernel, the APIC is assumed to be embedded to CPU, so KeRaise/LowerIrql are inlined as CR8 accesses.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

—
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