AW: global kernel lock

NTDEV
1
  1. You could also patch the import tables of drivers that import from the
    kernel.
  2. Or you could make a copy of the 4K page that contains the code to be
    patched and the update the page tables for this virtual address to point to
    your new page with a single atomic write and update of the CPU caches.

There’s also the problem of write protection into driver code segments on
W2K/WXP. Since you need to get around this somehow you’ll find 2) a good way
to do this.

Klaus

-----Urspr?ngliche Nachricht-----
Von: xxxxx@3Dlabs.com [mailto:xxxxx@3Dlabs.com]
Gesendet: Mittwoch, 14. Januar 2004 11:01
An: Windows System Software Devs Interest List
Betreff: RE: [ntdev] global kernel lock

Ok, so here’s ONE idea.

Read 8 bytes at the address you’re modifying, using an MMX register. Then
write mask out the first 5 bytes, and modify. Then store the value.

Using an MMX register should make it a “singe write operation”. If the
address is aligned to 8 bytes it should not be a problem to make the bus
transaction atomic. If the address isn’t aligned to 8 bytes, there’s little
you can do about it.

Note of course that you need to save FPU contents using the
“KeSaveFloatingPointState” and restore again with
“KeRestoreFloatingPointState”.

–
Mats

-----Original Message-----
From: xxxxx@sonydadc.com [mailto:xxxxx@sonydadc.com]
Sent: Wednesday, January 14, 2004 7:45 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] global kernel lock

Mats,

Thanks for your reply.

Sorry to have to ask, but: Why?
Unless you’re building a debugger or some such, there’s really no valid
case for “Must not be interrrupt by another thread”. There’s probably
something wrong in your design if “must” >do this. You should ever only need
to block threads that are accessing the same data as your own thread.

With the debugger you are not far away from the truth. I want to hook kernel
API functions, by overwriting the 1st 5 byte of the hooked function with a
“jmp xxx”. And as such a jmp instructions is 5 byte long, it can not be
written within one intruction. (My 1st idea was simply using a lock prefix )

So I need to prevent others from calling the API function during Iam writing
the “jmp xxx”.

(In the old WIn9x days I could simply use a kernel service hook, and I did
not find a similar solution for 2K, XP)

However, if you really want to do BAD design in your driver, a
KeRaiseIRQL() call with sufficently high IRQL will do the job. Obviously
followed by KeLowerIRQL(oldIRQL). [ OldIRQL is >passed back from the Raise
function]
It’s EXTREMELY bad practice to do this, however.
>You should never do this in a production driver.

Best Regards
Michael — Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 You are currently subscribed to
ntdev as: xxxxx@3dlabs.com To unsubscribe send a blank email to
xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@ati.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

2

Ok,

If implementing 2), you’d better also make sure that you allocate the pages
with “Execute” set, so that it doesn’t break when XP SP2 comes out, and the
code is run on a “Hardware virus protection (sic)” equipped AMD64 machine…

As long as it’s x86, I beleive you don’t need to do anything on the caches,
as the cache works on physical address, and all (modern) x86 processors have
snooping between instruction and data caches. You will have to invalidate
the TLB of course (INVLPG), but that should be it. Of course, on a
multiprocessor system, the INVLPG needs to be performed on ALL processors!

Of course, there’s still no sure way to guarantee that the other processor
hasn’t got the code that you’ve just modified in the pipeline, about to
execute it. Doesn’t matter what you do, this is almost impossible to
guarantee.

–
Mats
-----Original Message-----
From: Klaus Gerlicher [mailto:xxxxx@ati.com]
Sent: Wednesday, January 14, 2004 10:07 AM
To: Windows System Software Devs Interest List
Subject: AW: [ntdev] global kernel lock

  1. You could also patch the import tables of drivers that import from the
    kernel.
  2. Or you could make a copy of the 4K page that contains the code to be
    patched and the update the page tables for this virtual address to point to
    your new page with a single atomic write and update of the CPU caches.

There’s also the problem of write protection into driver code segments on
W2K/WXP. Since you need to get around this somehow you’ll find 2) a good way
to do this.

Klaus

-----Urspr?ngliche Nachricht-----
Von: xxxxx@3Dlabs.com [mailto:xxxxx@3Dlabs.com]
Gesendet: Mittwoch, 14. Januar 2004 11:01
An: Windows System Software Devs Interest List
Betreff: RE: [ntdev] global kernel lock

Ok, so here’s ONE idea.

Read 8 bytes at the address you’re modifying, using an MMX register. Then
write mask out the first 5 bytes, and modify. Then store the value.

Using an MMX register should make it a “singe write operation”. If the
address is aligned to 8 bytes it should not be a problem to make the bus
transaction atomic. If the address isn’t aligned to 8 bytes, there’s little
you can do about it.

Note of course that you need to save FPU contents using the
“KeSaveFloatingPointState” and restore again with
“KeRestoreFloatingPointState”.

–
Mats

-----Original Message-----
From: xxxxx@sonydadc.com [mailto:xxxxx@sonydadc.com]
Sent: Wednesday, January 14, 2004 7:45 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] global kernel lock

Mats,

Thanks for your reply.

Sorry to have to ask, but: Why?
Unless you’re building a debugger or some such, there’s really no valid
case for “Must not be interrrupt by another thread”. There’s probably
something wrong in your design if “must” >do this. You should ever only need
to block threads that are accessing the same data as your own thread.

With the debugger you are not far away from the truth. I want to hook kernel
API functions, by overwriting the 1st 5 byte of the hooked function with a
“jmp xxx”. And as such a jmp instructions is 5 byte long, it can not be
written within one intruction. (My 1st idea was simply using a lock prefix )

So I need to prevent others from calling the API function during Iam writing
the “jmp xxx”.

(In the old WIn9x days I could simply use a kernel service hook, and I did
not find a similar solution for 2K, XP)

However, if you really want to do BAD design in your driver, a
KeRaiseIRQL() call with sufficently high IRQL will do the job. Obviously
followed by KeLowerIRQL(oldIRQL). [ OldIRQL is >passed back from the Raise
function]
It’s EXTREMELY bad practice to do this, however.
>You should never do this in a production driver.

Best Regards
Michael — Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 You are currently subscribed to
ntdev as: xxxxx@3dlabs.com To unsubscribe send a blank email to
xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@ati.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Another possibilty could be ( if I’am right ) to adapt the plug in a way that you can still use the first byte of the instruction ( the instruction code JMP or CALL ) and only change the next four address information bytes. Those can be written with one atomic 32 bit write.

----- Original Message -----
From: xxxxx@3Dlabs.com
To: Windows System Software Devs Interest List
Sent: Wednesday, January 14, 2004 11:00 AM
Subject: RE: [ntdev] global kernel lock

Ok, so here’s ONE idea.

Read 8 bytes at the address you’re modifying, using an MMX register. Then write mask out the first 5 bytes, and modify. Then store the value.

Using an MMX register should make it a “singe write operation”. If the address is aligned to 8 bytes it should not be a problem to make the bus transaction atomic. If the address isn’t aligned to 8 bytes, there’s little you can do about it.

Note of course that you need to save FPU contents using the “KeSaveFloatingPointState” and restore again with “KeRestoreFloatingPointState”.

–
Mats

-----Original Message-----
From: xxxxx@sonydadc.com [mailto:xxxxx@sonydadc.com]
Sent: Wednesday, January 14, 2004 7:45 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] global kernel lock

Mats,

Thanks for your reply.

Sorry to have to ask, but: Why?
>Unless you’re building a debugger or some such, there’s really no valid case for “Must not be interrrupt by another thread”. There’s probably something wrong in your design if “must” >do this. You should ever only need to block threads that are accessing the same data as your own thread.

With the debugger you are not far away from the truth. I want to hook kernel API functions, by overwriting the 1st 5 byte of the hooked function with a “jmp xxx”. And as such a jmp instructions is 5 byte long, it can not be written within one intruction. (My 1st idea was simply using a lock prefix )
So I need to prevent others from calling the API function during Iam writing the “jmp xxx”.

(In the old WIn9x days I could simply use a kernel service hook, and I did not find a similar solution for 2K, XP)

However, if you really want to do BAD design in your driver, a KeRaiseIRQL() call with sufficently high IRQL will do the job. Obviously followed by KeLowerIRQL(oldIRQL). [OldIRQL is >passed back from the Raise function]
>It’s EXTREMELY bad practice to do this, however.
>You should never do this in a production driver.

Best Regards
Michael — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: xxxxx@3dlabs.com To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@compaqnet.be
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

Hooking INT3s and placing an INT3 into the code would also be a atomic
write. Softice does this.

-----Urspr?ngliche Nachricht-----
Von: Christiaan Ghijselinck [mailto:xxxxx@CompaqNet.be]
Gesendet: Mittwoch, 14. Januar 2004 11:32
An: Windows System Software Devs Interest List
Betreff: Re: [ntdev] global kernel lock

Another possibilty could be ( if I’am right ) to adapt the plug in a way
that you can still use the first byte of the instruction ( the instruction
code JMP or CALL ) and only change the next four address information bytes.
Those can be written with one atomic 32 bit write.

----- Original Message -----
From: xxxxx@3Dlabs.com mailto:xxxxx
To: Windows System mailto:xxxxx Software Devs Interest List

Sent: Wednesday, January 14, 2004 11:00 AM
Subject: RE: [ntdev] global kernel lock

Ok, so here’s ONE idea.

Read 8 bytes at the address you’re modifying, using an MMX register. Then
write mask out the first 5 bytes, and modify. Then store the value.

Using an MMX register should make it a “singe write operation”. If the
address is aligned to 8 bytes it should not be a problem to make the bus
transaction atomic. If the address isn’t aligned to 8 bytes, there’s little
you can do about it.

Note of course that you need to save FPU contents using the
“KeSaveFloatingPointState” and restore again with
“KeRestoreFloatingPointState”.

–
Mats

-----Original Message-----
From: xxxxx@sonydadc.com [mailto:xxxxx@sonydadc.com]
Sent: Wednesday, January 14, 2004 7:45 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] global kernel lock

Mats,

Thanks for your reply.

>Sorry to have to ask, but: Why?
>Unless you’re building a debugger or some such, there’s really no valid
case for “Must not be interrrupt by another thread”. There’s probably
something wrong in your design if “must” >do this. You should ever only need
to block threads that are accessing the same data as your own thread.

With the debugger you are not far away from the truth. I want to hook kernel
API functions, by overwriting the 1st 5 byte of the hooked function with a
“jmp xxx”. And as such a jmp instructions is 5 byte long, it can not be
written within one intruction. (My 1st idea was simply using a lock prefix )

So I need to prevent others from calling the API function during Iam writing
the “jmp xxx”.

(In the old WIn9x days I could simply use a kernel service hook, and I did
not find a similar solution for 2K, XP)

>However, if you really want to do BAD design in your driver, a
KeRaiseIRQL() call with sufficently high IRQL will do the job. Obviously
followed by KeLowerIRQL(oldIRQL). [OldIRQL is >passed back from the Raise
function]
>It’s EXTREMELY bad practice to do this, however.
>You should never do this in a production driver.

Best Regards
Michael — Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 You are currently subscribed to
ntdev as: xxxxx@3dlabs.com To unsubscribe send a blank email to
xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@compaqnet.be
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@ati.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx>

5

Nope. If the write isn’t on a word boundary it isn’t truely atomic at the bus level, even though it appears so at the instruction level. Now, if the whole 5 bytes are in a single cache line it will probably end up being atomic on the system bus, but I don’t think this is guaranteed. If the misaligned 4 bytes span a cache line then it most assuredly will not be atomic. Which is why the LOCK prefix doesn’t necessarily work on misaligned operands.

Loren
----- Original Message -----
From: Christiaan Ghijselinck
To: Windows System Software Devs Interest List
Sent: Wednesday, January 14, 2004 2:31 AM
Subject: Re: [ntdev] global kernel lock

Another possibilty could be ( if I’am right ) to adapt the plug in a way that you can still use the first byte of the instruction ( the instruction code JMP or CALL ) and only change the next four address information bytes. Those can be written with one atomic 32 bit write.

----- Original Message -----
From: xxxxx@3Dlabs.com
To: Windows System Software Devs Interest List
Sent: Wednesday, January 14, 2004 11:00 AM
Subject: RE: [ntdev] global kernel lock

Ok, so here’s ONE idea.

Read 8 bytes at the address you’re modifying, using an MMX register. Then write mask out the first 5 bytes, and modify. Then store the value.

Using an MMX register should make it a “singe write operation”. If the address is aligned to 8 bytes it should not be a problem to make the bus transaction atomic. If the address isn’t aligned to 8 bytes, there’s little you can do about it.

Note of course that you need to save FPU contents using the “KeSaveFloatingPointState” and restore again with “KeRestoreFloatingPointState”.

–
Mats

-----Original Message-----
From: xxxxx@sonydadc.com [mailto:xxxxx@sonydadc.com]
Sent: Wednesday, January 14, 2004 7:45 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] global kernel lock

Mats,

Thanks for your reply.

Sorry to have to ask, but: Why?
>Unless you’re building a debugger or some such, there’s really no valid case for “Must not be interrrupt by another thread”. There’s probably something wrong in your design if “must” >do this. You should ever only need to block threads that are accessing the same data as your own thread.

With the debugger you are not far away from the truth. I want to hook kernel API functions, by overwriting the 1st 5 byte of the hooked function with a “jmp xxx”. And as such a jmp instructions is 5 byte long, it can not be written within one intruction. (My 1st idea was simply using a lock prefix )
So I need to prevent others from calling the API function during Iam writing the “jmp xxx”.

(In the old WIn9x days I could simply use a kernel service hook, and I did not find a similar solution for 2K, XP)

However, if you really want to do BAD design in your driver, a KeRaiseIRQL() call with sufficently high IRQL will do the job. Obviously followed by KeLowerIRQL(oldIRQL). [OldIRQL is >passed back from the Raise function]
>It’s EXTREMELY bad practice to do this, however.
>You should never do this in a production driver.

Best Regards
Michael — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: xxxxx@3dlabs.com To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@compaqnet.be
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@earthlink.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

Hmm, does one have to also handle paging? I mean after the code was
patched one has to lock down the page somehow, or ?

Norbert.

“Faith is the ability to eat raspberry jam on a picnic without looking
to see if the seeds move.”
---- snip ----

7

Norbert,

It would probably be best to allocat the page in “Non-paged” memory,
assuming you don’t know that the page is certainly and always called from
IRQL (e.g. passive level) that allows paging. If it’s allocated from
non-paged memory, you don’t have to worry about it being paged out.

Otherwise, if you’re sure that paging is allowed when the code is executed,
just go ahead and allocate any old memory, and let the OS handle it.

–
Mats

-----Original Message-----
From: Norbert Kawulski [mailto:xxxxx@stollmann.de]
Sent: Wednesday, January 14, 2004 12:23 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] global kernel lock

Hmm, does one have to also handle paging? I mean after the code was
patched one has to lock down the page somehow, or ?

Norbert.

“Faith is the ability to eat raspberry jam on a picnic without looking
to see if the seeds move.”
---- snip ----

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

8

You still seem to be missing the overall point. You cannot stop NMI, no matter WHAT you do short of re-writing your own kernel or MacGyver the existing descriptor tables to control or disable NMI.

Why in the bloody hello are you trying to modify kernel API calls to jump to your own code? This isn’t “hooking” anything, it’s bludgeoning it to death, and this kind of behavior is normally expected by infectious and contagious vermin. What are you trying to do?

–
Gary G. Little
Seagate Technologies, LLC
wrote in message news:xxxxx@ntdev…

Mats,

Thanks for your reply.

>Sorry to have to ask, but: Why?
>Unless you’re building a debugger or some such, there’s really no valid case for “Must not be interrrupt by another thread”. There’s probably something wrong in your design if “must” >do this. You should ever only need to block threads that are accessing the same data as your own thread.

With the debugger you are not far away from the truth. I want to hook kernel API functions, by overwriting the 1st 5 byte of the hooked function with a “jmp xxx”. And as such a jmp instructions is 5 byte long, it can not be written within one intruction. (My 1st idea was simply using a lock prefix )
So I need to prevent others from calling the API function during Iam writing the “jmp xxx”.

(In the old WIn9x days I could simply use a kernel service hook, and I did not find a similar solution for 2K, XP)

>However, if you really want to do BAD design in your driver, a KeRaiseIRQL() call with sufficently high IRQL will do the job. Obviously followed by KeLowerIRQL(oldIRQL). [OldIRQL is >passed back from the Raise function]
>It’s EXTREMELY bad practice to do this, however.
>You should never do this in a production driver.

Best Regards
Michael

9

It’s actually very easy to stop NMI, I know at least two ways, but they
might make you blush, or worse, erupt into flame. :slight_smile: And while we’re at it,
we do that kind of thing all the time, not only in SoftICE but also in
BoundsChecker, TrueTime and TrueCoverage. I’m not going to say much, but
believe me, synchronization at hooking time is the least of your worries.
After much aggravation and bug chasing, we decided to write an SMP-safe
component that hooks code on demand for all our software - internally we
call it “Capt’n Hook”. And, believe me, NO, it isn’t a hack, nor is it any
less safe than anybody else’s code ! And it does precisely what Michael
wants to do. Which brings the point, I hate to put it that way, but can
DriverStudio be of service ? We have solved that problem many times over,
and both BoundsChecker and TrueTime allow you to add your own probe code to
your running driver.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Gary G. Little
Sent: Wednesday, January 14, 2004 9:19 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] global kernel lock

You still seem to be missing the overall point. You cannot stop NMI, no
matter WHAT you do short of re-writing your own kernel or MacGyver the
existing descriptor tables to control or disable NMI.

Why in the bloody hello are you trying to modify kernel API calls to jump to
your own code? This isn’t “hooking” anything, it’s bludgeoning it to death,
and this kind of behavior is normally expected by infectious and contagious
vermin. What are you trying to do?

–
Gary G. Little
Seagate Technologies, LLC

< xxxxx@sonydadc.com mailto:xxxxx > wrote in
message news:xxxxx@ntdev news:xxxxx …

Mats,

Thanks for your reply.

>Sorry to have to ask, but: Why?
>Unless you’re building a debugger or some such, there’s really no valid
case for “Must not be interrrupt by another thread”. There’s probably
something wrong in your design if “must” >do this. You should ever only need
to block threads that are accessing the same data as your own thread.

With the debugger you are not far away from the truth. I want to hook kernel
API functions, by overwriting the 1st 5 byte of the hooked function with a
“jmp xxx”. And as such a jmp instructions is 5 byte long, it can not be
written within one intruction. (My 1st idea was simply using a lock prefix )

So I need to prevent others from calling the API function during Iam writing
the “jmp xxx”.

(In the old WIn9x days I could simply use a kernel service hook, and I did
not find a similar solution for 2K, XP)

>However, if you really want to do BAD design in your driver, a
KeRaiseIRQL() call with sufficently high IRQL will do the job. Obviously
followed by KeLowerIRQL(oldIRQL). [OldIRQL is >passed back from the Raise
function]
>It’s EXTREMELY bad practice to do this, however.
>You should never do this in a production driver.

Best Regards
Michael

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.</news:xxxxx></mailto:xxxxx>

10

This is not really a new idea. About 6 moths ago, I ONCE SAID THAT ANY
LINKABLE KERNEL FUNCTION CAN BE PATCHED THIS WAY.

MAINILY THERE ARE TWO WAYS TO HOOK -

  1. Directly change the service table pointers

  2. Routing calls thru intermediate fuctions.

ALTERNATIVELY MUCH NEEDED IS TO HAVE A BONAFIED FILTER ARCHITECTURE ON THE
KERNEL SIDE, AND I HAVE NOT FOUND THIS YET.

Might be bad practice all together, but the above two methods are being used
by millions.

-PROKASH
“A virus is really an antivirus and vice versa”
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@sonydadc.com
Sent: Tuesday, January 13, 2004 11:45 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] global kernel lock

Mats,

Thanks for your reply.

Sorry to have to ask, but: Why?
>Unless you’re building a debugger or some such, there’s really no valid
case for “Must not be interrrupt by another thread”. There’s probably
something wrong in your design if “must” >do this. You should ever only need
to block threads that are accessing the same data as your own thread.

With the debugger you are not far away from the truth. I want to hook
kernel API functions, by overwriting the 1st 5 byte of the hooked function
with a “jmp xxx”. And as such a jmp instructions is 5 byte long, it can not
be written within one intruction. (My 1st idea was simply using a lock
prefix )
So I need to prevent others from calling the API function during Iam
writing the “jmp xxx”.

(In the old WIn9x days I could simply use a kernel service hook, and I did
not find a similar solution for 2K, XP)

However, if you really want to do BAD design in your driver, a
KeRaiseIRQL() call with sufficently high IRQL will do the job. Obviously
followed by KeLowerIRQL(oldIRQL). [ OldIRQL is >passed back from the Raise
function]
>It’s EXTREMELY bad practice to do this, however.
>You should never do this in a production driver.

Best Regards
Michael — Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 You are currently subscribed to
ntdev as: xxxxx@garlic.com To unsubscribe send a blank email to
xxxxx@lists.osr.com

11

Sorry for piggybacking.

I’m in need to investigate of getting BIOS level control. And I can see what
a battering I will have to face if I put the questions up here !!!

I dont want to have option BIOS or anything, but before OS (NT family only)
gets to the boot menu ( or in case of single boot start strapping) I need to
have control.
It should meet the BIOS specification, ACPI 2.0, and EFI.

Really appreciate, if I get some feedback as to where to look at besides
those specification(s). Sounds like HAL area.

-prokash
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Moreira, Alberto
Sent: Wednesday, January 14, 2004 6:28 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] global kernel lock

It’s actually very easy to stop NMI, I know at least two ways, but they
might make you blush, or worse, erupt into flame. :slight_smile: And while we’re at it,
we do that kind of thing all the time, not only in SoftICE but also in
BoundsChecker, TrueTime and TrueCoverage. I’m not going to say much, but
believe me, synchronization at hooking time is the least of your worries.
After much aggravation and bug chasing, we decided to write an SMP-safe
component that hooks code on demand for all our software - internally we
call it “Capt’n Hook”. And, believe me, NO, it isn’t a hack, nor is it any
less safe than anybody else’s code ! And it does precisely what Michael
wants to do. Which brings the point, I hate to put it that way, but can
DriverStudio be of service ? We have solved that problem many times over,
and both BoundsChecker and TrueTime allow you to add your own probe code to
your running driver.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Gary G. Little
Sent: Wednesday, January 14, 2004 9:19 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] global kernel lock

You still seem to be missing the overall point. You cannot stop NMI, no
matter WHAT you do short of re-writing your own kernel or MacGyver the
existing descriptor tables to control or disable NMI.

Why in the bloody hello are you trying to modify kernel API calls to
jump to your own code? This isn’t “hooking” anything, it’s bludgeoning it to
death, and this kind of behavior is normally expected by infectious and
contagious vermin. What are you trying to do?

–
Gary G. Little
Seagate Technologies, LLC
wrote in message news:xxxxx@ntdev…

Mats,

Thanks for your reply.

>Sorry to have to ask, but: Why?
>Unless you’re building a debugger or some such, there’s really no
valid case for “Must not be interrrupt by another thread”. There’s probably
something wrong in your design if “must” >do this. You should ever only need
to block threads that are accessing the same data as your own thread.

With the debugger you are not far away from the truth. I want to hook
kernel API functions, by overwriting the 1st 5 byte of the hooked function
with a “jmp xxx”. And as such a jmp instructions is 5 byte long, it can not
be written within one intruction. (My 1st idea was simply using a lock
prefix )
So I need to prevent others from calling the API function during Iam
writing the “jmp xxx”.

(In the old WIn9x days I could simply use a kernel service hook, and I
did not find a similar solution for 2K, XP)

>However, if you really want to do BAD design in your driver, a
KeRaiseIRQL() call with sufficently high IRQL will do the job. Obviously
followed by KeLowerIRQL(oldIRQL). [OldIRQL is >passed back from the Raise
function]
>It’s EXTREMELY bad practice to do this, however.
>You should never do this in a production driver.

Best Regards
Michael
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

12

Prokash Sinha wrote:

> This is not really a new idea. About 6 moths ago, I ONCE SAID THAT ANY
LINKABLE
> KERNEL FUNCTION CAN BE PATCHED THIS WAY.

> MAINILY THERE ARE TWO WAYS TO HOOK -

> 1) Directly change the service table pointers

> 2) Routing calls thru intermediate fuctions.

> ALTERNATIVELY MUCH NEEDED IS TO HAVE A BONAFIED FILTER
> ARCHITECTURE ON THE KERNEL SIDE, AND I HAVE NOT FOUND THIS YET.

Actually, what the OP is proposing isn’t either of those, he want to change
the actual code. This is not only very dangerous, but can cause tons of
problems.

I totally disagree with your statements of above on a filter architecture.
Right now we have a nightmare with filesystem filters in trying to test; in
part because the interactions of the various filters makes the testing
process huge. Adding a generalized filter mechanism to system and kernel
calls would increase the testing time of any program or driver by an order
of magnitude or more.

If you can show a good reason for a hook, argue it to Microsoft. But from
the various online forums most of the request are bogus, and only are only
being kept alive by bozos who don’t know better and say “sure go hook it”.

Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting

13

Before the OS gets control, you have to use an Option ROM on a PCI (or
similar) board.

Alternatively, you could perhaps build a boot manager type software, which
sits on the first few sectors of the hard disk. This is how you can boot
several different OS’s on the same machine. LILO in Linux is a good example.

–
Mats

-----Original Message-----
From: Prokash Sinha [mailto:xxxxx@garlic.com]
Sent: Wednesday, January 14, 2004 3:24 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] global kernel lock

Sorry for piggybacking.

I’m in need to investigate of getting BIOS level control. And I can see what
a battering I will have to face if I put the questions up here !!!

I dont want to have option BIOS or anything, but before OS (NT family only)
gets to the boot menu ( or in case of single boot start strapping) I need to
have control.
It should meet the BIOS specification, ACPI 2.0, and EFI.

Really appreciate, if I get some feedback as to where to look at besides
those specification(s). Sounds like HAL area.

-prokash

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Moreira, Alberto
Sent: Wednesday, January 14, 2004 6:28 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] global kernel lock

It’s actually very easy to stop NMI, I know at least two ways, but they
might make you blush, or worse, erupt into flame. :slight_smile: And while we’re at it,
we do that kind of thing all the time, not only in SoftICE but also in
BoundsChecker, TrueTime and TrueCoverage. I’m not going to say much, but
believe me, synchronization at hooking time is the least of your worries.
After much aggravation and bug chasing, we decided to write an SMP-safe
component that hooks code on demand for all our software - internally we
call it “Capt’n Hook”. And, believe me, NO, it isn’t a hack, nor is it any
less safe than anybody else’s code ! And it does precisely what Michael
wants to do. Which brings the point, I hate to put it that way, but can
DriverStudio be of service ? We have solved that problem many times over,
and both BoundsChecker and TrueTime allow you to add your own probe code to
your running driver.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Gary G. Little
Sent: Wednesday, January 14, 2004 9:19 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] global kernel lock

You still seem to be missing the overall point. You cannot stop NMI, no
matter WHAT you do short of re-writing your own kernel or MacGyver the
existing descriptor tables to control or disable NMI.

Why in the bloody hello are you trying to modify kernel API calls to jump to
your own code? This isn’t “hooking” anything, it’s bludgeoning it to death,
and this kind of behavior is normally expected by infectious and contagious
vermin. What are you trying to do?

–
Gary G. Little
Seagate Technologies, LLC

< xxxxx@sonydadc.com mailto:xxxxx > wrote in
message news:xxxxx@ntdev news:xxxxx …

Mats,

Thanks for your reply.

>Sorry to have to ask, but: Why?
>Unless you’re building a debugger or some such, there’s really no valid
case for “Must not be interrrupt by another thread”. There’s probably
something wrong in your design if “must” >do this. You should ever only need
to block threads that are accessing the same data as your own thread.

With the debugger you are not far away from the truth. I want to hook kernel
API functions, by overwriting the 1st 5 byte of the hooked function with a
“jmp xxx”. And as such a jmp instructions is 5 byte long, it can not be
written within one intruction. (My 1st idea was simply using a lock prefix )

So I need to prevent others from calling the API function during Iam writing
the “jmp xxx”.

(In the old WIn9x days I could simply use a kernel service hook, and I did
not find a similar solution for 2K, XP)

>However, if you really want to do BAD design in your driver, a
KeRaiseIRQL() call with sufficently high IRQL will do the job. Obviously
followed by KeLowerIRQL(oldIRQL). [OldIRQL is >passed back from the Raise
function]
>It’s EXTREMELY bad practice to do this, however.
>You should never do this in a production driver.

Best Regards
Michael

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</news:xxxxx></mailto:xxxxx>

14

Sorry that those two points does not cover the OP’s intention.

It has been well reported to Microsoft. They know it. Whether it got
percolated up to the right node or not is unknown.

I surely agree with you that anything forbidden and possibly could have a
very bad affect on the system(s) should not be persued, but there should be
clear indication from Microsoft people, I mean a very sharp indication
substantiate with alternative suggestion(s). Believe or not it is a much
needed area ( at least for the class of bozos !!!. And sometime one has to
be a bozo to fend off bozo attacks, really I mean it ).

As someone said "Performance, Performance, and … " really matters in some
area specially netfiltering etc., and I’ve not seen a better performance
than some of these ugly ideas !!!.

For the filter(s), if it is too cumbersome, it should be simplified. Very
very large code base always would have problems when it evolves, but that is
not an excuse.

-prokash

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Don Burn
Sent: Wednesday, January 14, 2004 7:26 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] global kernel lock

Prokash Sinha wrote:

> This is not really a new idea. About 6 moths ago, I ONCE SAID THAT ANY
LINKABLE
> KERNEL FUNCTION CAN BE PATCHED THIS WAY.

> MAINILY THERE ARE TWO WAYS TO HOOK -

> 1) Directly change the service table pointers

> 2) Routing calls thru intermediate fuctions.

> ALTERNATIVELY MUCH NEEDED IS TO HAVE A BONAFIED FILTER
> ARCHITECTURE ON THE KERNEL SIDE, AND I HAVE NOT FOUND THIS YET.

Actually, what the OP is proposing isn’t either of those, he want to change
the actual code. This is not only very dangerous, but can cause tons of
problems.

I totally disagree with your statements of above on a filter architecture.
Right now we have a nightmare with filesystem filters in trying to test; in
part because the interactions of the various filters makes the testing
process huge. Adding a generalized filter mechanism to system and kernel
calls would increase the testing time of any program or driver by an order
of magnitude or more.

If you can show a good reason for a hook, argue it to Microsoft. But from
the various online forums most of the request are bogus, and only are only
being kept alive by bozos who don’t know better and say “sure go hook it”.

Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

15

Yea,

I thought about looking at the OpenBios and LILO boot manager. Definitely we
want to avoid any option bios, if possible.

thans for the pointer.

-prokash
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@3Dlabs.com
Sent: Wednesday, January 14, 2004 7:35 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] global kernel lock

Before the OS gets control, you have to use an Option ROM on a PCI (or
similar) board.

Alternatively, you could perhaps build a boot manager type software, which
sits on the first few sectors of the hard disk. This is how you can boot
several different OS’s on the same machine. LILO in Linux is a good example.

–
Mats
-----Original Message-----
From: Prokash Sinha [mailto:xxxxx@garlic.com]
Sent: Wednesday, January 14, 2004 3:24 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] global kernel lock

Sorry for piggybacking.

I’m in need to investigate of getting BIOS level control. And I can see
what a battering I will have to face if I put the questions up here !!!

I dont want to have option BIOS or anything, but before OS (NT family
only) gets to the boot menu ( or in case of single boot start strapping) I
need to have control.
It should meet the BIOS specification, ACPI 2.0, and EFI.

Really appreciate, if I get some feedback as to where to look at besides
those specification(s). Sounds like HAL area.

-prokash
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Moreira, Alberto
Sent: Wednesday, January 14, 2004 6:28 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] global kernel lock

It’s actually very easy to stop NMI, I know at least two ways, but
they might make you blush, or worse, erupt into flame. :slight_smile: And while we’re
at it, we do that kind of thing all the time, not only in SoftICE but also
in BoundsChecker, TrueTime and TrueCoverage. I’m not going to say much, but
believe me, synchronization at hooking time is the least of your worries.
After much aggravation and bug chasing, we decided to write an SMP-safe
component that hooks code on demand for all our software - internally we
call it “Capt’n Hook”. And, believe me, NO, it isn’t a hack, nor is it any
less safe than anybody else’s code ! And it does precisely what Michael
wants to do. Which brings the point, I hate to put it that way, but can
DriverStudio be of service ? We have solved that problem many times over,
and both BoundsChecker and TrueTime allow you to add your own probe code to
your running driver.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Gary G. Little
Sent: Wednesday, January 14, 2004 9:19 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] global kernel lock

You still seem to be missing the overall point. You cannot stop NMI,
no matter WHAT you do short of re-writing your own kernel or MacGyver the
existing descriptor tables to control or disable NMI.

Why in the bloody hello are you trying to modify kernel API calls to
jump to your own code? This isn’t “hooking” anything, it’s bludgeoning it to
death, and this kind of behavior is normally expected by infectious and
contagious vermin. What are you trying to do?

–
Gary G. Little
Seagate Technologies, LLC
wrote in message news:xxxxx@ntdev…

Mats,

Thanks for your reply.

>Sorry to have to ask, but: Why?
>Unless you’re building a debugger or some such, there’s really no
valid case for “Must not be interrrupt by another thread”. There’s probably
something wrong in your design if “must” >do this. You should ever only need
to block threads that are accessing the same data as your own thread.

With the debugger you are not far away from the truth. I want to
hook kernel API functions, by overwriting the 1st 5 byte of the hooked
function with a “jmp xxx”. And as such a jmp instructions is 5 byte long, it
can not be written within one intruction. (My 1st idea was simply using a
lock prefix )
So I need to prevent others from calling the API function during
Iam writing the “jmp xxx”.

(In the old WIn9x days I could simply use a kernel service hook,
and I did not find a similar solution for 2K, XP)

>However, if you really want to do BAD design in your driver, a
KeRaiseIRQL() call with sufficently high IRQL will do the job. Obviously
followed by KeLowerIRQL(oldIRQL). [OldIRQL is >passed back from the Raise
function]
>It’s EXTREMELY bad practice to do this, however.
>You should never do this in a production driver.

Best Regards
Michael
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@compuware.com
To unsubscribe send a blank email to
xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com