RE: Compiler aligning/optimisation Was: IRQL = 0xFF

NTDEV
1

Martin Harvey wrote:

Actually, now you come to mention it, I can think of one situation
where a compiler would want to pad code with nops, but it’s pretty
arcane. Some optimising compilers might, in the interests of speed,
decide that it was worth ensuring that a short inner loop didn’t
cross a an L2 cache line boundary - it can cause bank conflicts
where the caches end up thrashing (http://www.agner.org/assem/pentopt.pdf
), and the instruction fetch on PII / PIII processors fetches in 16
byte aligned blocks, so there’s a decode penalty too.

However, to be honest, I don’t know of any compilers that deal with
this: normally, they just perform transformations on the
intermediate representation, perform register allocation by
colouring and nesting level, and then generate the ops with a tree
matching algorithm, with possibly some special cases dependent on
architecture, and then do a bit of peephole optimization to remove
redundancies.

Well, you obviously don’t know of any compilers then :slight_smile:

I would say that all modern compilers (MS VC 6/.Net, GCC, Intel ICC, etc)
are all doing various tricks to align the code to make the best possible
use of the processor speed. They aren’t always perfect, and there are a
number of options that may change the balance between small code-size and
alignment padding, but any compiler with the least pretence to produce
optimised code will do some padding of functions, loops, etc. Not doing so
would encourage a competitor to come in and steal market share.

If you look carefully at the code generated by the compiler in various
areas of your driver, you’ll find a lot of NOP/INT3/other no-op codes in
there. “Other no-op codes” are quite frequently used when the alignment is
in a path that may be executed, as in this case we want to fill as many
bytes as possible with one instruction to avoid stuffing the execution
units full of “nothing to do” instructions.

–
Mats

MH.

2

LOL - ok, let me rephrase that - I’ve seen compilers align functions as
a whole, typically filling in between with int3, but I hadn’t seen
compilers fill the executable path with no-ops.

MH.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
Sent: 10 February 2005 17:47
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Compiler aligning/optimisation Was: IRQL = 0xFF

Well, you obviously don’t know of any compilers then :slight_smile:

This email and any attachments is confidential, may be legally privileged and is intended for the use of the addressee only. If you are not the intended recipient, please note that any use, disclosure, printing or copying of this email is strictly prohibited and may be unlawful. If received in error, please delete this email and any attachments and confirm this to the sender.

3

I have seen such code generated by VC .Net, but I can’t produce a sample
that shows it at the moment (spending no more than about 10 minutes on
trying… :wink:

It probably depends on the complexity of the code, and maybe other
conditions too…

–
Mats

-------- Notice --------
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of the message, or any
action taken by you in reliance on it, is prohibited and may be unlawful.
If you have received this message in error, please delete it and contact
the sender immediately. Thank you.

xxxxx@lists.osr.com wrote on 02/11/2005 09:53:59 AM:

LOL - ok, let me rephrase that - I’ve seen compilers align functions as
a whole, typically filling in between with int3, but I hadn’t seen
compilers fill the executable path with no-ops.

MH.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
Sent: 10 February 2005 17:47
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Compiler aligning/optimisation Was: IRQL = 0xFF

Well, you obviously don’t know of any compilers then :slight_smile:

This email and any attachments is confidential, may be legally
privileged and is intended for the use of the addressee only. If you
are not the intended recipient, please note that any use,
disclosure, printing or copying of this email is strictly prohibited
and may be unlawful. If received in error, please delete this email
and any attachments and confirm this to the sender.

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

ForwardSourceID:NT0000CC66

4

I think the patch point idea is right. It looks like this is only done on
dllexport functions. I couldn’t find any “internal” functions with this
preamble.

I didn’t see this on my machine at first because the machine I checked was
running Server. For whatever reason it was done only on XP.

I think the real proof would be to find one with a jump patched in.

CB

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin C Harvey
Sent: Friday, February 11, 2005 4:54 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Compiler aligning/optimisation Was: IRQL = 0xFF

LOL - ok, let me rephrase that - I’ve seen compilers align functions as
a whole, typically filling in between with int3, but I hadn’t seen
compilers fill the executable path with no-ops.

MH.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
Sent: 10 February 2005 17:47
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Compiler aligning/optimisation Was: IRQL = 0xFF

Well, you obviously don’t know of any compilers then :slight_smile:

This email and any attachments is confidential, may be legally privileged
and is intended for the use of the addressee only. If you are not the
intended recipient, please note that any use, disclosure, printing or
copying of this email is strictly prohibited and may be unlawful. If
received in error, please delete this email and any attachments and confirm
this to the sender.

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

Thanks for the info, I didn’t know the switch (and hadn’t compiled my driver
for w2k3 :slight_smile:

From “TC” on 19 November, 2004:
http://www.datarescue.com/ubb/ultimatebb.php?/topic/1/694.html#000015
Years ago, there was a humorous Internet posting that described the
“Microsoft Universal Exploit API”, designed to standardize the creation of
viruses for Microsoft OSs. Perhaps we’ve now seen that implemented :slight_smile:

Personal thoughts:

  • I tried to find the reference without success. Even though MS say that
    they don’t support hooks by setting the service table read-only, it’s
    becoming much more easy do to hooking this way.

  • Microsoft never really cared about alignment so don’t try to find
    alignment noops in their compiled binaries. They known that memory uses was
    far more important than small performance gain. So when you see noop in
    their binaries, there is usually a (good) reason.

  • But I guess that on server-side, it can be quite useful on servers or data
    centers with high availability to do hot patching for limited bug fixes. I
    would have done it this way too :slight_smile:

M-A

a écrit dans le message de news: xxxxx@ntdev…
Well after someone’s previous post mentioning this hot patch idea, I noticed
that our drivers, being built with the 2003 ddk, now have these no-op
instructions at the head of ALL functions, both internal and exported. I
then went and looked at the assembler output from the compiler and each
function starts off with “npad 2” that translates to that “mov edi, edi”
instruction. Then I found that this is controlled by the compiler switch
/hotpatch. The pads between the functions is controlled by the linker switch
/functionpadmin. These switches are set by the DDK build in the file
i386mk.inc and there isn’t any convenient way for the developer to turn them
off other than by modifying i386mk.inc.

One of our guys here thought that maybe these were being put in for Driver
Verifier. I could see that if they were only on exported functions, but then
why the internal functions too?

I would guess that the performance hit of having these things in there would
be negligible, so I’m not going to lose a lot of sleep over it.

Jerry.

6

__declspec(dllexport) produces mangled names as exports (like _MyFunc@8),
and thus is frowned upon.
I’m absolutely sure Windows kernel is built using a DEF file. And, in this
case, the compiler does not know what functions will be exported.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Centis Biks”
To: “Windows System Software Devs Interest List”
Sent: Friday, February 11, 2005 3:13 PM
Subject: RE: [ntdev] Compiler aligning/optimisation Was: IRQL = 0xFF

> I think the patch point idea is right. It looks like this is only done on
> dllexport functions. I couldn’t find any “internal” functions with this
> preamble.
>
> I didn’t see this on my machine at first because the machine I checked was
> running Server. For whatever reason it was done only on XP.
>
> I think the real proof would be to find one with a jump patched in.
>
> CB
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Martin C Harvey
> Sent: Friday, February 11, 2005 4:54 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Compiler aligning/optimisation Was: IRQL = 0xFF
>
>
> LOL - ok, let me rephrase that - I’ve seen compilers align functions as
> a whole, typically filling in between with int3, but I hadn’t seen
> compilers fill the executable path with no-ops.
>
> MH.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
> Sent: 10 February 2005 17:47
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Compiler aligning/optimisation Was: IRQL = 0xFF
>
> Well, you obviously don’t know of any compilers then :slight_smile:
>
> This email and any attachments is confidential, may be legally privileged
> and is intended for the use of the addressee only. If you are not the
> intended recipient, please note that any use, disclosure, printing or
> copying of this email is strictly prohibited and may be unlawful. If
> received in error, please delete this email and any attachments and confirm
> this to the sender.
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> 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@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

7

xxxxx@attotech.com wrote:

Well after someone’s previous post mentioning this hot patch idea, I
noticed that our drivers, being built with the 2003 ddk, now have these
no-op instructions at the head of ALL functions, both internal and
exported.

Nice find.

I then went and looked at the assembler output from the
compiler and each function starts off with “npad 2” that translates to
that “mov edi, edi” instruction. Then I found that this is controlled by
the compiler switch /hotpatch. The pads between the functions is
controlled by the linker switch /functionpadmin. These switches are set
by the DDK build in the file i386mk.inc and there isn’t any convenient
way for the developer to turn them off other than by modifying i386mk.inc.

One of our guys here thought that maybe these were being put in for
Driver Verifier. I could see that if they were only on exported
functions, but then why the internal functions too?

To the best of my knowledge, it’s not related to Driver Verifier.

I CAN tell you that the compiler, linker, and build environment (right
down to the compiler and linker options specified) in the DDK are
identical to those used to build the matching build of the Windows OS.
It’s makes sense (I have no information one way or the other, this is
truly just a guess) that Windows is built with these no-ops in its
functions to facilitate hotpatching. If that’s the case, then given that
the DDK build environment is identical to that used to build the OS, it
would explain why those options are present when you build drivers in
the DDK.

Peter
OSR

8

Well then I’d have to say that it is a disgusting waste of
resources. Quite understandable in a development
environment but “waste cycles just in case” in a production
system is crazy. It may explain why my 400MHz PII
running a different operating system (not *n*x) outperforms
my 3.4GHz HT P4 on some tasks. I don’t want anyone
to hook anything ever on my computers. That kinda *fix*
was deprecated more than 20 years ago.

I’d like to hear disagreements. If it’s “cause the OS is broken”
I’ll file it away.

Regards,

brucee

On Fri, 11 Feb 2005 23:43:34 -0500, Peter Viscarola (OSR)
wrote:
> xxxxx@attotech.com wrote:
> > Well after someone’s previous post mentioning this hot patch idea, I
> > noticed that our drivers, being built with the 2003 ddk, now have these
> > no-op instructions at the head of ALL functions, both internal and
> > exported.
>
> Nice find.
>
> > I then went and looked at the assembler output from the
> > compiler and each function starts off with “npad 2” that translates to
> > that “mov edi, edi” instruction. Then I found that this is controlled by
> > the compiler switch /hotpatch. The pads between the functions is
> > controlled by the linker switch /functionpadmin. These switches are set
> > by the DDK build in the file i386mk.inc and there isn’t any convenient
> > way for the developer to turn them off other than by modifying i386mk.inc.
> >
> > One of our guys here thought that maybe these were being put in for
> > Driver Verifier. I could see that if they were only on exported
> > functions, but then why the internal functions too?
> >
>
> To the best of my knowledge, it’s not related to Driver Verifier.
>
> I CAN tell you that the compiler, linker, and build environment (right
> down to the compiler and linker options specified) in the DDK are
> identical to those used to build the matching build of the Windows OS.
> It’s makes sense (I have no information one way or the other, this is
> truly just a guess) that Windows is built with these no-ops in its
> functions to facilitate hotpatching. If that’s the case, then given that
> the DDK build environment is identical to that used to build the OS, it
> would explain why those options are present when you build drivers in
> the DDK.
>
> Peter
> OSR
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

9

First, I dont belive that it is easier to hook when there are zero or more
nop either at the top of function prolog or anywhere in a routine. Also SDT
is not the only place people go for it, even though all are equally
dangerous. So leave that aside !.

Now I think someone mentioned instruction pairing. Also there are possibly
other things in mind, pipe-line stall, data hazard, instruction hazard,
fetch alignment, and so many other things compiler writers need to worry
about, so a cycle or two ( with a byte or two ) loosing here and there could
be thought of as investment, so that the overall performance could be
better. Just by looking at those nop does not give enough to say that the
genrated code is bad. On the top of it, there are phy/logical
multiprocessing.

SO IT IS REALLY HARD TO JUMP INTO ANY CONCLUSION LIKE THIS !!!

-pro
----- Original Message -----
From: “Bruce Ellis”
To: “Windows System Software Devs Interest List”
Sent: Friday, February 11, 2005 9:08 PM
Subject: Re: [ntdev] Compiler aligning/optimisation Was: IRQL = 0xFF

> Well then I’d have to say that it is a disgusting waste of
> resources. Quite understandable in a development
> environment but “waste cycles just in case” in a production
> system is crazy. It may explain why my 400MHz PII
> running a different operating system (not nx) outperforms
> my 3.4GHz HT P4 on some tasks. I don’t want anyone
> to hook anything ever on my computers. That kinda fix
> was deprecated more than 20 years ago.
>
> I’d like to hear disagreements. If it’s “cause the OS is broken”
> I’ll file it away.
>
> Regards,
>
> brucee
>
> On Fri, 11 Feb 2005 23:43:34 -0500, Peter Viscarola (OSR)
> wrote:
> > xxxxx@attotech.com wrote:
> > > Well after someone’s previous post mentioning this hot patch idea, I
> > > noticed that our drivers, being built with the 2003 ddk, now have
these
> > > no-op instructions at the head of ALL functions, both internal and
> > > exported.
> >
> > Nice find.
> >
> > > I then went and looked at the assembler output from the
> > > compiler and each function starts off with “npad 2” that translates to
> > > that “mov edi, edi” instruction. Then I found that this is controlled
by
> > > the compiler switch /hotpatch. The pads between the functions is
> > > controlled by the linker switch /functionpadmin. These switches are
set
> > > by the DDK build in the file i386mk.inc and there isn’t any convenient
> > > way for the developer to turn them off other than by modifying
i386mk.inc.
> > >
> > > One of our guys here thought that maybe these were being put in for
> > > Driver Verifier. I could see that if they were only on exported
> > > functions, but then why the internal functions too?
> > >
> >
> > To the best of my knowledge, it’s not related to Driver Verifier.
> >
> > I CAN tell you that the compiler, linker, and build environment (right
> > down to the compiler and linker options specified) in the DDK are
> > identical to those used to build the matching build of the Windows OS.
> > It’s makes sense (I have no information one way or the other, this is
> > truly just a guess) that Windows is built with these no-ops in its
> > functions to facilitate hotpatching. If that’s the case, then given that
> > the DDK build environment is identical to that used to build the OS, it
> > would explain why those options are present when you build drivers in
> > the DDK.
> >
> > Peter
> > OSR
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.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
>

10

My conclusion is from experience, not a jump.
I write compilers and operatings systems.
Please read some x86 documentation and jump
anywhere you like.

brucee

On Fri, 11 Feb 2005 22:06:38 -0800, Prokash Sinha wrote:
> First, I dont belive that it is easier to hook when there are zero or more
> nop either at the top of function prolog or anywhere in a routine. Also SDT
> is not the only place people go for it, even though all are equally
> dangerous. So leave that aside !.
>
> Now I think someone mentioned instruction pairing. Also there are possibly
> other things in mind, pipe-line stall, data hazard, instruction hazard,
> fetch alignment, and so many other things compiler writers need to worry
> about, so a cycle or two ( with a byte or two ) loosing here and there could
> be thought of as investment, so that the overall performance could be
> better. Just by looking at those nop does not give enough to say that the
> genrated code is bad. On the top of it, there are phy/logical
> multiprocessing.
>
> SO IT IS REALLY HARD TO JUMP INTO ANY CONCLUSION LIKE THIS !!!
>
> -pro
> ----- Original Message -----
> From: “Bruce Ellis”
> To: “Windows System Software Devs Interest List”
> Sent: Friday, February 11, 2005 9:08 PM
> Subject: Re: [ntdev] Compiler aligning/optimisation Was: IRQL = 0xFF
>
> > Well then I’d have to say that it is a disgusting waste of
> > resources. Quite understandable in a development
> > environment but “waste cycles just in case” in a production
> > system is crazy. It may explain why my 400MHz PII
> > running a different operating system (not nx) outperforms
> > my 3.4GHz HT P4 on some tasks. I don’t want anyone
> > to hook anything ever on my computers. That kinda fix
> > was deprecated more than 20 years ago.
> >
> > I’d like to hear disagreements. If it’s “cause the OS is broken”
> > I’ll file it away.
> >
> > Regards,
> >
> > brucee
> >
> > On Fri, 11 Feb 2005 23:43:34 -0500, Peter Viscarola (OSR)
> > wrote:
> > > xxxxx@attotech.com wrote:
> > > > Well after someone’s previous post mentioning this hot patch idea, I
> > > > noticed that our drivers, being built with the 2003 ddk, now have
> these
> > > > no-op instructions at the head of ALL functions, both internal and
> > > > exported.
> > >
> > > Nice find.
> > >
> > > > I then went and looked at the assembler output from the
> > > > compiler and each function starts off with “npad 2” that translates to
> > > > that “mov edi, edi” instruction. Then I found that this is controlled
> by
> > > > the compiler switch /hotpatch. The pads between the functions is
> > > > controlled by the linker switch /functionpadmin. These switches are
> set
> > > > by the DDK build in the file i386mk.inc and there isn’t any convenient
> > > > way for the developer to turn them off other than by modifying
> i386mk.inc.
> > > >
> > > > One of our guys here thought that maybe these were being put in for
> > > > Driver Verifier. I could see that if they were only on exported
> > > > functions, but then why the internal functions too?
> > > >
> > >
> > > To the best of my knowledge, it’s not related to Driver Verifier.
> > >
> > > I CAN tell you that the compiler, linker, and build environment (right
> > > down to the compiler and linker options specified) in the DDK are
> > > identical to those used to build the matching build of the Windows OS.
> > > It’s makes sense (I have no information one way or the other, this is
> > > truly just a guess) that Windows is built with these no-ops in its
> > > functions to facilitate hotpatching. If that’s the case, then given that
> > > the DDK build environment is identical to that used to build the OS, it
> > > would explain why those options are present when you build drivers in
> > > the DDK.
> > >
> > > Peter
> > > OSR
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@gmail.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
> >
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

11

Pro,

It actually is easier to hook over no-ops. First of all, you
don’t have to move the existing instructions out and put them
somewhere where you can execute them from,when you finally
decide to go back to the original code. One of those
instructions might be a jump or a call that requires you to
recompute your own relocation. Because i386 instructions are
variable length, and because the instruction set isn’t as
regular as one would want it to be, you may need to do a fair
amount of processing just to figure out how many bytes to remove
and where to stop executing the code you obliterated.

And there are other problems. For example, code that jumps back
to the second instruction, which happens to be a 5-byte
instruction that follows a 2-byte instruction, and you have put
a 5-byte jump over it: the code jumps to the middle of your jump
target address, and bang, the system goes into la-la land. More,
if you’re hooking with a 5-byte instruction, that’s two write
accesses, and you have to worry about the eventuality that
someone jumps to your target code between the moment you wrote
the first word and the moment you wrote the second. Or, maybe
the code you’re trying to intercept starts with a two-byte jump,
or it happens to be a little stub that’s less than 5 bytes long,
and bang, you crash again.

Then you say, well, I’ll just put a one-byte Int 3 instruction
in there, or even a two-byte int. And then you clash with the
debugger-that-be, or with someone else’s ISR, or someone comes
and clobbers your int with their own code, or, or, or…

Ah, the joys of writing machine level code. Believe me, those
no-ops are a welcome sight! And gents, no flames, please.
Someone has to write those debuggers and bounds-checkers and
performance monitoring tools and what not.

Alberto.

----- Original Message -----
From: “Prokash Sinha”
To: “Windows System Software Devs Interest List”

Sent: Saturday, February 12, 2005 1:06 AM
Subject: Re: [ntdev] Compiler aligning/optimisation Was: IRQL =
0xFF

> First, I dont belive that it is easier to hook when there are
> zero or more
> nop either at the top of function prolog or anywhere in a
> routine. Also SDT
> is not the only place people go for it, even though all are
> equally
> dangerous. So leave that aside !.
>
> Now I think someone mentioned instruction pairing. Also there
> are possibly
> other things in mind, pipe-line stall, data hazard,
> instruction hazard,
> fetch alignment, and so many other things compiler writers
> need to worry
> about, so a cycle or two ( with a byte or two ) loosing here
> and there could
> be thought of as investment, so that the overall performance
> could be
> better. Just by looking at those nop does not give enough to
> say that the
> genrated code is bad. On the top of it, there are phy/logical
> multiprocessing.
>
> SO IT IS REALLY HARD TO JUMP INTO ANY CONCLUSION LIKE THIS
> !!!
>
> -pro
> ----- Original Message -----
> From: “Bruce Ellis”
> To: “Windows System Software Devs Interest List”
>
> Sent: Friday, February 11, 2005 9:08 PM
> Subject: Re: [ntdev] Compiler aligning/optimisation Was: IRQL
> = 0xFF
>
>
>> Well then I’d have to say that it is a disgusting waste of
>> resources. Quite understandable in a development
>> environment but “waste cycles just in case” in a production
>> system is crazy. It may explain why my 400MHz PII
>> running a different operating system (not nx) outperforms
>> my 3.4GHz HT P4 on some tasks. I don’t want anyone
>> to hook anything ever on my computers. That kinda fix
>> was deprecated more than 20 years ago.
>>
>> I’d like to hear disagreements. If it’s “cause the OS is
>> broken”
>> I’ll file it away.
>>
>> Regards,
>>
>> brucee
>>
>> On Fri, 11 Feb 2005 23:43:34 -0500, Peter Viscarola (OSR)
>> wrote:
>> > xxxxx@attotech.com wrote:
>> > > Well after someone’s previous post mentioning this hot
>> > > patch idea, I
>> > > noticed that our drivers, being built with the 2003 ddk,
>> > > now have
> these
>> > > no-op instructions at the head of ALL functions, both
>> > > internal and
>> > > exported.
>> >
>> > Nice find.
>> >
>> > > I then went and looked at the assembler output from the
>> > > compiler and each function starts off with “npad 2” that
>> > > translates to
>> > > that “mov edi, edi” instruction. Then I found that this
>> > > is controlled
> by
>> > > the compiler switch /hotpatch. The pads between the
>> > > functions is
>> > > controlled by the linker switch /functionpadmin. These
>> > > switches are
> set
>> > > by the DDK build in the file i386mk.inc and there isn’t
>> > > any convenient
>> > > way for the developer to turn them off other than by
>> > > modifying
> i386mk.inc.
>> > >
>> > > One of our guys here thought that maybe these were being
>> > > put in for
>> > > Driver Verifier. I could see that if they were only on
>> > > exported
>> > > functions, but then why the internal functions too?
>> > >
>> >
>> > To the best of my knowledge, it’s not related to Driver
>> > Verifier.
>> >
>> > I CAN tell you that the compiler, linker, and build
>> > environment (right
>> > down to the compiler and linker options specified) in the
>> > DDK are
>> > identical to those used to build the matching build of the
>> > Windows OS.
>> > It’s makes sense (I have no information one way or the
>> > other, this is
>> > truly just a guess) that Windows is built with these no-ops
>> > in its
>> > functions to facilitate hotpatching. If that’s the case,
>> > then given that
>> > the DDK build environment is identical to that used to
>> > build the OS, it
>> > would explain why those options are present when you build
>> > drivers in
>> > the DDK.
>> >
>> > Peter
>> > OSR
>> >
>> > —
>> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>> >
>> > You are currently subscribed to ntdev as:
>> > xxxxx@gmail.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
>>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com

12

I disagree. Leaving around dead code intended to be patched
shows complete distrust in the code base. And for every function?
A few bytes here and there, a few cache lines blown away.
I don’t want it. I’ve never had to hook an OS call in my life,
though patching binaries is nothing new to me.

So can I buy a Win* without this hook crap? I just did a quick
test of adding 3 nops at the beginning of every function to my
compiler. Try it - you’ll enjoy the downgrade.

brucee

On Sat, 12 Feb 2005 09:52:56 -0500, Alberto Moreira wrote:
> Pro,
>
> It actually is easier to hook over no-ops. First of all, you
> don’t have to move the existing instructions out and put them
> somewhere where you can execute them from,when you finally
> decide to go back to the original code. One of those
> instructions might be a jump or a call that requires you to
> recompute your own relocation. Because i386 instructions are
> variable length, and because the instruction set isn’t as
> regular as one would want it to be, you may need to do a fair
> amount of processing just to figure out how many bytes to remove
> and where to stop executing the code you obliterated.
>
> And there are other problems. For example, code that jumps back
> to the second instruction, which happens to be a 5-byte
> instruction that follows a 2-byte instruction, and you have put
> a 5-byte jump over it: the code jumps to the middle of your jump
> target address, and bang, the system goes into la-la land. More,
> if you’re hooking with a 5-byte instruction, that’s two write
> accesses, and you have to worry about the eventuality that
> someone jumps to your target code between the moment you wrote
> the first word and the moment you wrote the second. Or, maybe
> the code you’re trying to intercept starts with a two-byte jump,
> or it happens to be a little stub that’s less than 5 bytes long,
> and bang, you crash again.
>
> Then you say, well, I’ll just put a one-byte Int 3 instruction
> in there, or even a two-byte int. And then you clash with the
> debugger-that-be, or with someone else’s ISR, or someone comes
> and clobbers your int with their own code, or, or, or…
>
> Ah, the joys of writing machine level code. Believe me, those
> no-ops are a welcome sight! And gents, no flames, please.
> Someone has to write those debuggers and bounds-checkers and
> performance monitoring tools and what not.
>
> Alberto.
>
>
> ----- Original Message -----
> From: “Prokash Sinha”
> To: “Windows System Software Devs Interest List”
>
> Sent: Saturday, February 12, 2005 1:06 AM
> Subject: Re: [ntdev] Compiler aligning/optimisation Was: IRQL =
> 0xFF
>
> > First, I dont belive that it is easier to hook when there are
> > zero or more
> > nop either at the top of function prolog or anywhere in a
> > routine. Also SDT
> > is not the only place people go for it, even though all are
> > equally
> > dangerous. So leave that aside !.
> >
> > Now I think someone mentioned instruction pairing. Also there
> > are possibly
> > other things in mind, pipe-line stall, data hazard,
> > instruction hazard,
> > fetch alignment, and so many other things compiler writers
> > need to worry
> > about, so a cycle or two ( with a byte or two ) loosing here
> > and there could
> > be thought of as investment, so that the overall performance
> > could be
> > better. Just by looking at those nop does not give enough to
> > say that the
> > genrated code is bad. On the top of it, there are phy/logical
> > multiprocessing.
> >
> > SO IT IS REALLY HARD TO JUMP INTO ANY CONCLUSION LIKE THIS
> > !!!
> >
> > -pro
> > ----- Original Message -----
> > From: “Bruce Ellis”
> > To: “Windows System Software Devs Interest List”
> >
> > Sent: Friday, February 11, 2005 9:08 PM
> > Subject: Re: [ntdev] Compiler aligning/optimisation Was: IRQL
> > = 0xFF
> >
> >
> >> Well then I’d have to say that it is a disgusting waste of
> >> resources. Quite understandable in a development
> >> environment but “waste cycles just in case” in a production
> >> system is crazy. It may explain why my 400MHz PII
> >> running a different operating system (not nx) outperforms
> >> my 3.4GHz HT P4 on some tasks. I don’t want anyone
> >> to hook anything ever on my computers. That kinda fix
> >> was deprecated more than 20 years ago.
> >>
> >> I’d like to hear disagreements. If it’s “cause the OS is
> >> broken”
> >> I’ll file it away.
> >>
> >> Regards,
> >>
> >> brucee
> >>
> >> On Fri, 11 Feb 2005 23:43:34 -0500, Peter Viscarola (OSR)
> >> wrote:
> >> > xxxxx@attotech.com wrote:
> >> > > Well after someone’s previous post mentioning this hot
> >> > > patch idea, I
> >> > > noticed that our drivers, being built with the 2003 ddk,
> >> > > now have
> > these
> >> > > no-op instructions at the head of ALL functions, both
> >> > > internal and
> >> > > exported.
> >> >
> >> > Nice find.
> >> >
> >> > > I then went and looked at the assembler output from the
> >> > > compiler and each function starts off with “npad 2” that
> >> > > translates to
> >> > > that “mov edi, edi” instruction. Then I found that this
> >> > > is controlled
> > by
> >> > > the compiler switch /hotpatch. The pads between the
> >> > > functions is
> >> > > controlled by the linker switch /functionpadmin. These
> >> > > switches are
> > set
> >> > > by the DDK build in the file i386mk.inc and there isn’t
> >> > > any convenient
> >> > > way for the developer to turn them off other than by
> >> > > modifying
> > i386mk.inc.
> >> > >
> >> > > One of our guys here thought that maybe these were being
> >> > > put in for
> >> > > Driver Verifier. I could see that if they were only on
> >> > > exported
> >> > > functions, but then why the internal functions too?
> >> > >
> >> >
> >> > To the best of my knowledge, it’s not related to Driver
> >> > Verifier.
> >> >
> >> > I CAN tell you that the compiler, linker, and build
> >> > environment (right
> >> > down to the compiler and linker options specified) in the
> >> > DDK are
> >> > identical to those used to build the matching build of the
> >> > Windows OS.
> >> > It’s makes sense (I have no information one way or the
> >> > other, this is
> >> > truly just a guess) that Windows is built with these no-ops
> >> > in its
> >> > functions to facilitate hotpatching. If that’s the case,
> >> > then given that
> >> > the DDK build environment is identical to that used to
> >> > build the OS, it
> >> > would explain why those options are present when you build
> >> > drivers in
> >> > the DDK.
> >> >
> >> > Peter
> >> > OSR
> >> >
> >> > —
> >> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >> >
> >> > You are currently subscribed to ntdev as:
> >> > xxxxx@gmail.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
> >>
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@ieee.org
> > 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@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

13

> So can I buy a Win* without this hook crap?

Are you sure this is a hook crap and not an optimization to help some alignment
or pairing?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

14

The point was from the malicious point of view, if an entity can do a
patch do a binary with nops at the head of f( ), then it is not that hard to
do for g( ) w/o nops …

But for sure for the debugging/management tools it is easier w/nops.

As to the performance, I always think about perceived_peformance. Again, a
single program tweaked to perform better on Pantium II w/o much of OS bagage
does not simply satisfy my craving. I’ve 386 (0x8086 was dumped long-time
back), Pant-1(100Mz), Pant-II ( ~334Mz), Pant-IV-HT, and other machines, so
sooner or later I would be able to prove that I’m a real stupid to gradually
upgrade for new OSes, and that can only be proved when I see most of the
programs (compilers,tools, office, explorer, etc., etc ) are slowing down(in
a perceived manner) due to : nop, nop, nop… Also I’ve not seen significant
balzing fast Linux ( on my HP Nx suse8.1 laptop)…Seriously.

Again, for Alberto, it is all the better(to have nop, nop, nop ) for tools
vendors as you mentioned.

-pro

----- Original Message -----
From: “Bruce Ellis”
To: “Windows System Software Devs Interest List”
Sent: Saturday, February 12, 2005 7:06 AM
Subject: Re: [ntdev] Compiler aligning/optimisation Was: IRQL = 0xFF

> I disagree. Leaving around dead code intended to be patched
> shows complete distrust in the code base. And for every function?
> A few bytes here and there, a few cache lines blown away.
> I don’t want it. I’ve never had to hook an OS call in my life,
> though patching binaries is nothing new to me.
>
> So can I buy a Win* without this hook crap? I just did a quick
> test of adding 3 nops at the beginning of every function to my
> compiler. Try it - you’ll enjoy the downgrade.
>
> brucee
>
> On Sat, 12 Feb 2005 09:52:56 -0500, Alberto Moreira
wrote:
> > Pro,
> >
> > It actually is easier to hook over no-ops. First of all, you
> > don’t have to move the existing instructions out and put them
> > somewhere where you can execute them from,when you finally
> > decide to go back to the original code. One of those
> > instructions might be a jump or a call that requires you to
> > recompute your own relocation. Because i386 instructions are
> > variable length, and because the instruction set isn’t as
> > regular as one would want it to be, you may need to do a fair
> > amount of processing just to figure out how many bytes to remove
> > and where to stop executing the code you obliterated.
> >
> > And there are other problems. For example, code that jumps back
> > to the second instruction, which happens to be a 5-byte
> > instruction that follows a 2-byte instruction, and you have put
> > a 5-byte jump over it: the code jumps to the middle of your jump
> > target address, and bang, the system goes into la-la land. More,
> > if you’re hooking with a 5-byte instruction, that’s two write
> > accesses, and you have to worry about the eventuality that
> > someone jumps to your target code between the moment you wrote
> > the first word and the moment you wrote the second. Or, maybe
> > the code you’re trying to intercept starts with a two-byte jump,
> > or it happens to be a little stub that’s less than 5 bytes long,
> > and bang, you crash again.
> >
> > Then you say, well, I’ll just put a one-byte Int 3 instruction
> > in there, or even a two-byte int. And then you clash with the
> > debugger-that-be, or with someone else’s ISR, or someone comes
> > and clobbers your int with their own code, or, or, or…
> >
> > Ah, the joys of writing machine level code. Believe me, those
> > no-ops are a welcome sight! And gents, no flames, please.
> > Someone has to write those debuggers and bounds-checkers and
> > performance monitoring tools and what not.
> >
> > Alberto.
> >
> >
> > ----- Original Message -----
> > From: “Prokash Sinha”
> > To: “Windows System Software Devs Interest List”
> >
> > Sent: Saturday, February 12, 2005 1:06 AM
> > Subject: Re: [ntdev] Compiler aligning/optimisation Was: IRQL =
> > 0xFF
> >
> > > First, I dont belive that it is easier to hook when there are
> > > zero or more
> > > nop either at the top of function prolog or anywhere in a
> > > routine. Also SDT
> > > is not the only place people go for it, even though all are
> > > equally
> > > dangerous. So leave that aside !.
> > >
> > > Now I think someone mentioned instruction pairing. Also there
> > > are possibly
> > > other things in mind, pipe-line stall, data hazard,
> > > instruction hazard,
> > > fetch alignment, and so many other things compiler writers
> > > need to worry
> > > about, so a cycle or two ( with a byte or two ) loosing here
> > > and there could
> > > be thought of as investment, so that the overall performance
> > > could be
> > > better. Just by looking at those nop does not give enough to
> > > say that the
> > > genrated code is bad. On the top of it, there are phy/logical
> > > multiprocessing.
> > >
> > > SO IT IS REALLY HARD TO JUMP INTO ANY CONCLUSION LIKE THIS
> > > !!!
> > >
> > > -pro
> > > ----- Original Message -----
> > > From: “Bruce Ellis”
> > > To: “Windows System Software Devs Interest List”
> > >
> > > Sent: Friday, February 11, 2005 9:08 PM
> > > Subject: Re: [ntdev] Compiler aligning/optimisation Was: IRQL
> > > = 0xFF
> > >
> > >
> > >> Well then I’d have to say that it is a disgusting waste of
> > >> resources. Quite understandable in a development
> > >> environment but “waste cycles just in case” in a production
> > >> system is crazy. It may explain why my 400MHz PII
> > >> running a different operating system (not nx) outperforms
> > >> my 3.4GHz HT P4 on some tasks. I don’t want anyone
> > >> to hook anything ever on my computers. That kinda fix
> > >> was deprecated more than 20 years ago.
> > >>
> > >> I’d like to hear disagreements. If it’s “cause the OS is
> > >> broken”
> > >> I’ll file it away.
> > >>
> > >> Regards,
> > >>
> > >> brucee
> > >>
> > >> On Fri, 11 Feb 2005 23:43:34 -0500, Peter Viscarola (OSR)
> > >> wrote:
> > >> > xxxxx@attotech.com wrote:
> > >> > > Well after someone’s previous post mentioning this hot
> > >> > > patch idea, I
> > >> > > noticed that our drivers, being built with the 2003 ddk,
> > >> > > now have
> > > these
> > >> > > no-op instructions at the head of ALL functions, both
> > >> > > internal and
> > >> > > exported.
> > >> >
> > >> > Nice find.
> > >> >
> > >> > > I then went and looked at the assembler output from the
> > >> > > compiler and each function starts off with “npad 2” that
> > >> > > translates to
> > >> > > that “mov edi, edi” instruction. Then I found that this
> > >> > > is controlled
> > > by
> > >> > > the compiler switch /hotpatch. The pads between the
> > >> > > functions is
> > >> > > controlled by the linker switch /functionpadmin. These
> > >> > > switches are
> > > set
> > >> > > by the DDK build in the file i386mk.inc and there isn’t
> > >> > > any convenient
> > >> > > way for the developer to turn them off other than by
> > >> > > modifying
> > > i386mk.inc.
> > >> > >
> > >> > > One of our guys here thought that maybe these were being
> > >> > > put in for
> > >> > > Driver Verifier. I could see that if they were only on
> > >> > > exported
> > >> > > functions, but then why the internal functions too?
> > >> > >
> > >> >
> > >> > To the best of my knowledge, it’s not related to Driver
> > >> > Verifier.
> > >> >
> > >> > I CAN tell you that the compiler, linker, and build
> > >> > environment (right
> > >> > down to the compiler and linker options specified) in the
> > >> > DDK are
> > >> > identical to those used to build the matching build of the
> > >> > Windows OS.
> > >> > It’s makes sense (I have no information one way or the
> > >> > other, this is
> > >> > truly just a guess) that Windows is built with these no-ops
> > >> > in its
> > >> > functions to facilitate hotpatching. If that’s the case,
> > >> > then given that
> > >> > the DDK build environment is identical to that used to
> > >> > build the OS, it
> > >> > would explain why those options are present when you build
> > >> > drivers in
> > >> > the DDK.
> > >> >
> > >> > Peter
> > >> > OSR
> > >> >
> > >> > —
> > >> > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >> >
> > >> > You are currently subscribed to ntdev as:
> > >> > xxxxx@gmail.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
> > >>
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@ieee.org
> > > 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@gmail.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
>

15

> a perceived manner) due to : nop, nop, nop… Also I’ve not seen significant

balzing fast Linux ( on my HP Nx suse8.1 laptop)…Seriously.

Compare to FreeBSD, I think the latter has better VM and filesystem.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

16

> It’s makes sense (I have no information one way or the other,

this is truly just a guess) that Windows is built with these
no-ops in its functions to facilitate hotpatching.

Here is a guess, they’re for code coverage analysis. Perhaps the
experimental driver signing based on code coverage has proven to be
extreemly effective.

Another guess is some enhancement for running the OS in a virtual machine.
One virtual machine architecture would basically gobble up the normal code,
and spit out the same code with some extra code to deal with difference in
the virtual vs. normal execution environment. This extra code must take
space, and it might be helpful if there was already filler space spread
through the binary. This would basically be run-time (or maybe load time)
patching of the OS binary in place. I assume virtual machines currently must
have to keep two copies of the code, the original and the modified, although
if the VM was all in user mode, everything could be pagable.

  • Jan
17

Come on. The padding is not there to make things more efficient.
That answers one speculation. Alignment means almost nothing
for code on x86 - though if the compiler aligns each function to
a cache line you win a bit *and this is not done by adding nops
for hooking*.

You may enjoy the functionality of hooking but to be honest, it
was deprecated in the 70s. - check the literature.

Hooking any system call in any clean OS I’ve worked on is as easy
as a call to a process management function (all done in user mode).

brucee.

18

Well, you could say I’m a professional hooker :slight_smile: I do debuggers
and that kind of stuff, so, hooking to me is a way of life. And
it’s a poor kernel debugger which will rely on an OS call while
debugging, in my mind one of the cornerstones of debugging is
that you never use any piece of code that might become the
debugee, or you never really know wether you’re running clean.
But as I was thinking of it, I came with a more sinister and
more cynical explanation: putting a noop in front of every
routine gives you an easy way to check if your code has been
hooked, and act accordingly, for example, by reloading the code
from a clean file. It’s easy to defeat, but still, it’ll catch a
fair amount of those cases.

Alberto.

----- Original Message -----
From: “Bruce Ellis”
To: “Windows System Software Devs Interest List”

Sent: Sunday, February 13, 2005 2:27 AM
Subject: Re: [ntdev] Compiler aligning/optimisation Was: IRQL =
0xFF

> Come on. The padding is not there to make things more
> efficient.
> That answers one speculation. Alignment means almost nothing
> for code on x86 - though if the compiler aligns each function
> to
> a cache line you win a bit and this is not done by adding
> nops
> for hooking.
>
> You may enjoy the functionality of hooking but to be honest,
> it
> was deprecated in the 70s. - check the literature.
>
> Hooking any system call in any clean OS I’ve worked on is as
> easy
> as a call to a process management function (all done in user
> mode).
>
> brucee.
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com

19

You say you added 3 nops to the beginning of every function of your
compiler. How great was the performance drop?

Did you put them in as asm { } blocks? Does your compiler optimize code
around asm blocks?

I’m really curious to see what sort of a “downgrade” you’re talking
about.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bruce Ellis
Sent: Saturday, February 12, 2005 7:06 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Compiler aligning/optimisation Was: IRQL = 0xFF

I disagree. Leaving around dead code intended to be patched shows
complete distrust in the code base. And for every function?
A few bytes here and there, a few cache lines blown away.
I don’t want it. I’ve never had to hook an OS call in my life, though
patching binaries is nothing new to me.

So can I buy a Win* without this hook crap? I just did a quick test of
adding 3 nops at the beginning of every function to my compiler. Try it

  • you’ll enjoy the downgrade.

brucee

On Sat, 12 Feb 2005 09:52:56 -0500, Alberto Moreira
wrote:
> Pro,
>
> It actually is easier to hook over no-ops. First of all, you don’t
> have to move the existing instructions out and put them somewhere
> where you can execute them from,when you finally decide to go back to
> the original code. One of those instructions might be a jump or a call

> that requires you to recompute your own relocation. Because i386
> instructions are variable length, and because the instruction set
> isn’t as regular as one would want it to be, you may need to do a fair

> amount of processing just to figure out how many bytes to remove and
> where to stop executing the code you obliterated.
>
> And there are other problems. For example, code that jumps back to the

> second instruction, which happens to be a 5-byte instruction that
> follows a 2-byte instruction, and you have put a 5-byte jump over it:
> the code jumps to the middle of your jump target address, and bang,
> the system goes into la-la land. More, if you’re hooking with a 5-byte

> instruction, that’s two write accesses, and you have to worry about
> the eventuality that someone jumps to your target code between the
> moment you wrote the first word and the moment you wrote the second.
> Or, maybe the code you’re trying to intercept starts with a two-byte
> jump, or it happens to be a little stub that’s less than 5 bytes long,

> and bang, you crash again.
>
> Then you say, well, I’ll just put a one-byte Int 3 instruction in
> there, or even a two-byte int. And then you clash with the
> debugger-that-be, or with someone else’s ISR, or someone comes and
> clobbers your int with their own code, or, or, or…
>
> Ah, the joys of writing machine level code. Believe me, those no-ops
> are a welcome sight! And gents, no flames, please.
> Someone has to write those debuggers and bounds-checkers and
> performance monitoring tools and what not.
>
> Alberto.
>
>
> ----- Original Message -----
> From: “Prokash Sinha”
> To: “Windows System Software Devs Interest List”
>
> Sent: Saturday, February 12, 2005 1:06 AM
> Subject: Re: [ntdev] Compiler aligning/optimisation Was: IRQL = 0xFF
>
> > First, I dont belive that it is easier to hook when there are zero
> > or more nop either at the top of function prolog or anywhere in a
> > routine. Also SDT is not the only place people go for it, even
> > though all are equally dangerous. So leave that aside !.
> >
> > Now I think someone mentioned instruction pairing. Also there are
> > possibly other things in mind, pipe-line stall, data hazard,
> > instruction hazard, fetch alignment, and so many other things
> > compiler writers need to worry about, so a cycle or two ( with a
> > byte or two ) loosing here and there could be thought of as
> > investment, so that the overall performance could be better. Just by

> > looking at those nop does not give enough to say that the genrated
> > code is bad. On the top of it, there are phy/logical
> > multiprocessing.
> >
> > SO IT IS REALLY HARD TO JUMP INTO ANY CONCLUSION LIKE THIS
> > !!!
> >
> > -pro
> > ----- Original Message -----
> > From: “Bruce Ellis”
> > To: “Windows System Software Devs Interest List”
> >
> > Sent: Friday, February 11, 2005 9:08 PM
> > Subject: Re: [ntdev] Compiler aligning/optimisation Was: IRQL = 0xFF
> >
> >
> >> Well then I’d have to say that it is a disgusting waste of
> >> resources. Quite understandable in a development
> >> environment but “waste cycles just in case” in a production
> >> system is crazy. It may explain why my 400MHz PII
> >> running a different operating system (not nx) outperforms
> >> my 3.4GHz HT P4 on some tasks. I don’t want anyone
> >> to hook anything ever on my computers. That kinda fix
> >> was deprecated more than 20 years ago.
> >>
> >> I’d like to hear disagreements. If it’s “cause the OS is
> >> broken”
> >> I’ll file it away.
> >>
> >> Regards,
> >>
> >> brucee
> >>
> >> On Fri, 11 Feb 2005 23:43:34 -0500, Peter Viscarola (OSR)
> >> wrote:
> >> > xxxxx@attotech.com wrote:
> >> > > Well after someone’s previous post mentioning this hot
> >> > > patch idea, I
> >> > > noticed that our drivers, being built with the 2003 ddk,
> >> > > now have
> > these
> >> > > no-op instructions at the head of ALL functions, both
> >> > > internal and
> >> > > exported.
> >> >
> >> > Nice find.
> >> >
> >> > > I then went and looked at the assembler output from the
> >> > > compiler and each function starts off with “npad 2” that
> >> > > translates to
> >> > > that “mov edi, edi” instruction. Then I found that this
> >> > > is controlled
> > by
> >> > > the compiler switch /hotpatch. The pads between the
> >> > > functions is
> >> > > controlled by the linker switch /functionpadmin. These
> >> > > switches are
> > set
> >> > > by the DDK build in the file i386mk.inc and there isn’t
> >> > > any convenient
> >> > > way for the developer to turn them off other than by
> >> > > modifying
> > i386mk.inc.
> >> > >
> >> > > One of our guys here thought that maybe these were being
> >> > > put in for
> >> > > Driver Verifier. I could see that if they were only on
> >> > > exported
> >> > > functions, but then why the internal functions too?
> >> > >
> >> >
> >> > To the best of my knowledge, it’s not related to Driver
> >> > Verifier.
> >> >
> >> > I CAN tell you that the compiler, linker, and build
> >> > environment (right
> >> > down to the compiler and linker options specified) in the
> >> > DDK are
> >> > identical to those used to build the matching build of the
> >> > Windows OS.
> >> > It’s makes sense (I have no information one way or the
> >> > other, this is
> >> > truly just a guess) that Windows is built with these no-ops
> >> > in its
> >> > functions to facilitate hotpatching. If that’s the case,
> >> > then given that
> >> > the DDK build environment is identical to that used to
> >> > build the OS, it
> >> > would explain why those options are present when you build
> >> > drivers in
> >> > the DDK.
> >> >
> >> > Peter
> >> > OSR
> >> >
> >> > —
> >> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >> >
> >> > You are currently subscribed to ntdev as:
> >> > xxxxx@gmail.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
> >>
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@ieee.org
> > 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@gmail.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@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

20

The compiler inserts the nops after all optimization. The degredation
of course depends on the size of functions! And many other factors,
like working set size vs cache size and occupancy of pipelines
*before* the call. It can be a few percent or much more on contrived
cases. It can be almost 0 in cases when the program is very data
intensive so the pipes are nearly always blocked and not full.

If you want them then that’s your choice.
I don’t want them, and I don’t want anyone to hook me.

brucee

On Sun, 13 Feb 2005 12:29:05 -0800, Peter Wieland
wrote:
> You say you added 3 nops to the beginning of every function of your
> compiler. How great was the performance drop?
>
> Did you put them in as asm { } blocks? Does your compiler optimize code
> around asm blocks?
>
> I’m really curious to see what sort of a “downgrade” you’re talking
> about.
>
> -p
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Bruce Ellis
> Sent: Saturday, February 12, 2005 7:06 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Compiler aligning/optimisation Was: IRQL = 0xFF
>
> I disagree. Leaving around dead code intended to be patched shows
> complete distrust in the code base. And for every function?
> A few bytes here and there, a few cache lines blown away.
> I don’t want it. I’ve never had to hook an OS call in my life, though
> patching binaries is nothing new to me.
>
> So can I buy a Win* without this hook crap? I just did a quick test of
> adding 3 nops at the beginning of every function to my compiler. Try it
> - you’ll enjoy the downgrade.
>
> brucee
>
> On Sat, 12 Feb 2005 09:52:56 -0500, Alberto Moreira
> wrote:
> > Pro,
> >
> > It actually is easier to hook over no-ops. First of all, you don’t
> > have to move the existing instructions out and put them somewhere
> > where you can execute them from,when you finally decide to go back to
> > the original code. One of those instructions might be a jump or a call
>
> > that requires you to recompute your own relocation. Because i386
> > instructions are variable length, and because the instruction set
> > isn’t as regular as one would want it to be, you may need to do a fair
>
> > amount of processing just to figure out how many bytes to remove and
> > where to stop executing the code you obliterated.
> >
> > And there are other problems. For example, code that jumps back to the
>
> > second instruction, which happens to be a 5-byte instruction that
> > follows a 2-byte instruction, and you have put a 5-byte jump over it:
> > the code jumps to the middle of your jump target address, and bang,
> > the system goes into la-la land. More, if you’re hooking with a 5-byte
>
> > instruction, that’s two write accesses, and you have to worry about
> > the eventuality that someone jumps to your target code between the
> > moment you wrote the first word and the moment you wrote the second.
> > Or, maybe the code you’re trying to intercept starts with a two-byte
> > jump, or it happens to be a little stub that’s less than 5 bytes long,
>
> > and bang, you crash again.
> >
> > Then you say, well, I’ll just put a one-byte Int 3 instruction in
> > there, or even a two-byte int. And then you clash with the
> > debugger-that-be, or with someone else’s ISR, or someone comes and
> > clobbers your int with their own code, or, or, or…
> >
> > Ah, the joys of writing machine level code. Believe me, those no-ops
> > are a welcome sight! And gents, no flames, please.
> > Someone has to write those debuggers and bounds-checkers and
> > performance monitoring tools and what not.
> >
> > Alberto.
> >
> >
> > ----- Original Message -----
> > From: “Prokash Sinha”
> > To: “Windows System Software Devs Interest List”
> >
> > Sent: Saturday, February 12, 2005 1:06 AM
> > Subject: Re: [ntdev] Compiler aligning/optimisation Was: IRQL = 0xFF
> >
> > > First, I dont belive that it is easier to hook when there are zero
> > > or more nop either at the top of function prolog or anywhere in a
> > > routine. Also SDT is not the only place people go for it, even
> > > though all are equally dangerous. So leave that aside !.
> > >
> > > Now I think someone mentioned instruction pairing. Also there are
> > > possibly other things in mind, pipe-line stall, data hazard,
> > > instruction hazard, fetch alignment, and so many other things
> > > compiler writers need to worry about, so a cycle or two ( with a
> > > byte or two ) loosing here and there could be thought of as
> > > investment, so that the overall performance could be better. Just by
>
> > > looking at those nop does not give enough to say that the genrated
> > > code is bad. On the top of it, there are phy/logical
> > > multiprocessing.
> > >
> > > SO IT IS REALLY HARD TO JUMP INTO ANY CONCLUSION LIKE THIS
> > > !!!
> > >
> > > -pro
> > > ----- Original Message -----
> > > From: “Bruce Ellis”
> > > To: “Windows System Software Devs Interest List”
> > >
> > > Sent: Friday, February 11, 2005 9:08 PM
> > > Subject: Re: [ntdev] Compiler aligning/optimisation Was: IRQL = 0xFF
> > >
> > >
> > >> Well then I’d have to say that it is a disgusting waste of
> > >> resources. Quite understandable in a development
> > >> environment but “waste cycles just in case” in a production
> > >> system is crazy. It may explain why my 400MHz PII
> > >> running a different operating system (not nx) outperforms
> > >> my 3.4GHz HT P4 on some tasks. I don’t want anyone
> > >> to hook anything ever on my computers. That kinda fix
> > >> was deprecated more than 20 years ago.
> > >>
> > >> I’d like to hear disagreements. If it’s “cause the OS is
> > >> broken”
> > >> I’ll file it away.
> > >>
> > >> Regards,
> > >>
> > >> brucee
> > >>
> > >> On Fri, 11 Feb 2005 23:43:34 -0500, Peter Viscarola (OSR)
> > >> wrote:
> > >> > xxxxx@attotech.com wrote:
> > >> > > Well after someone’s previous post mentioning this hot
> > >> > > patch idea, I
> > >> > > noticed that our drivers, being built with the 2003 ddk,
> > >> > > now have
> > > these
> > >> > > no-op instructions at the head of ALL functions, both
> > >> > > internal and
> > >> > > exported.
> > >> >
> > >> > Nice find.
> > >> >
> > >> > > I then went and looked at the assembler output from the
> > >> > > compiler and each function starts off with “npad 2” that
> > >> > > translates to
> > >> > > that “mov edi, edi” instruction. Then I found that this
> > >> > > is controlled
> > > by
> > >> > > the compiler switch /hotpatch. The pads between the
> > >> > > functions is
> > >> > > controlled by the linker switch /functionpadmin. These
> > >> > > switches are
> > > set
> > >> > > by the DDK build in the file i386mk.inc and there isn’t
> > >> > > any convenient
> > >> > > way for the developer to turn them off other than by
> > >> > > modifying
> > > i386mk.inc.
> > >> > >
> > >> > > One of our guys here thought that maybe these were being
> > >> > > put in for
> > >> > > Driver Verifier. I could see that if they were only on
> > >> > > exported
> > >> > > functions, but then why the internal functions too?
> > >> > >
> > >> >
> > >> > To the best of my knowledge, it’s not related to Driver
> > >> > Verifier.
> > >> >
> > >> > I CAN tell you that the compiler, linker, and build
> > >> > environment (right
> > >> > down to the compiler and linker options specified) in the
> > >> > DDK are
> > >> > identical to those used to build the matching build of the
> > >> > Windows OS.
> > >> > It’s makes sense (I have no information one way or the
> > >> > other, this is
> > >> > truly just a guess) that Windows is built with these no-ops
> > >> > in its
> > >> > functions to facilitate hotpatching. If that’s the case,
> > >> > then given that
> > >> > the DDK build environment is identical to that used to
> > >> > build the OS, it
> > >> > would explain why those options are present when you build
> > >> > drivers in
> > >> > the DDK.
> > >> >
> > >> > Peter
> > >> > OSR
> > >> >
> > >> > —
> > >> > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >> >
> > >> > You are currently subscribed to ntdev as:
> > >> > xxxxx@gmail.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
> > >>
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@ieee.org
> > > 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@gmail.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@windows.microsoft.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: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>