suppressing /hotpatch in ddk build environment

How do I suppress the /hotpatch switch in the ddkbuild environment? In
fact, I want to do just the opposite. I want to make sure that my driver is
NOT hot patchable. How do I do that?

I am using DDKBUILD VERSION 3.12.35 from HOLLIS TECHNOLOGY SOLUTIONS.

Regards,

George.

jeffm
Wed Jan 04 14:06:37 CST 2006

------=_NextPart_0001_37C764B8
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

George,

For that information, I believe you will need to ask the DDKBUILD vendor.

Try http://www.hollistech.com/.

Thanks,
[MSFT] Jeff McCashland
jeffm@online.microsoft.com

This posting is provided "AS IS" with no warranties, and confers no rights.
------=_NextPart_0001_37C764B8
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 George,
\par
\par For that information, I believe you will need to ask the DDKBUILD vendor.
\par
\par Try http://www.hollistech.com/.
\par
\par Thanks,
\par [MSFT] Jeff McCashland
\par jeffm@online.microsoft.com
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par
\par }
------=_NextPart_0001_37C764B8--

Mark
Wed Jan 04 21:49:25 CST 2006

On Wed, 04 Jan 2006 20:06:37 GMT, jeffm@online.microsoft.com (Jeff
McCashland [MSFT]) wrote:

>George,
>
>For that information, I believe you will need to ask the DDKBUILD vendor.
>
>Try http://www.hollistech.com/.
>
>Thanks,
>[MSFT] Jeff McCashland
>jeffm@online.microsoft.com
>
>This posting is provided "AS IS" with no warranties, and confers no rights.

I don't qualify as a vendor here, for that I would have to actually
vend something :-)

I give up what the heck is '/hotpatch'? I don't find this listed as a
parameter for build. Nor is it mentioned anywhere in the ddk docs.

Ah - I see it is a compiler flag. Its use is undocumented in the DDK
and its support is some even more undocumented nonsense buried deep
within the build support files. Hmmm.. perhaps the OP ought to ask the
vendor of build about that?

Looks to me like there is no way to turn it off on the command line so
no help from ddkbuild. You might try clobbering ERATTA_FLAGS in your
sources file. But now I am curious, why do you think you need to
disable this?

I generally try not to muck too much with the builtin rules for driver
compilation/linking.



=====================
Mark Roddy DDK MVP
Windows Vista/2003/XP/2000 Consulting
Device and Filesystem Drivers
Hollis Technology Solutions 603-321-1032
www.hollistech.com

RossettoeCioccolato
Thu Jan 05 02:50:57 CST 2006

Mark,

Thanks for clarifying this. I thought that this was a Microsoft issue to
begin with; and a pretty nasty bug in my opinion. Perhaps there are some
restricted circumstances where the benefits of hot patching outweigh the
inherent security risks. But I don't see why this switch should be turned
on by default.

Once again, would someone from Microsoft please explain how to turn this
switch off within the DDK build environment?

Regards,

George.

"Mark Roddy" <markr@hollistech.com> schrieb im Newsbeitrag
news:015pr1tikav8opvfghrb7krijqtlro6sm8@4ax.com...
> On Wed, 04 Jan 2006 20:06:37 GMT, jeffm@online.microsoft.com (Jeff
> McCashland [MSFT]) wrote:
>
>>George,
>>
>>For that information, I believe you will need to ask the DDKBUILD vendor.
>>
>>Try http://www.hollistech.com/.
>>
>>Thanks,
>>[MSFT] Jeff McCashland
>>jeffm@online.microsoft.com
>>
>>This posting is provided "AS IS" with no warranties, and confers no
>>rights.
>
> I don't qualify as a vendor here, for that I would have to actually
> vend something :-)
>
> I give up what the heck is '/hotpatch'? I don't find this listed as a
> parameter for build. Nor is it mentioned anywhere in the ddk docs.
>
> Ah - I see it is a compiler flag. Its use is undocumented in the DDK
> and its support is some even more undocumented nonsense buried deep
> within the build support files. Hmmm.. perhaps the OP ought to ask the
> vendor of build about that?
>
> Looks to me like there is no way to turn it off on the command line so
> no help from ddkbuild. You might try clobbering ERATTA_FLAGS in your
> sources file. But now I am curious, why do you think you need to
> disable this?
>
> I generally try not to muck too much with the builtin rules for driver
> compilation/linking.
>
>
>
> =====================
> Mark Roddy DDK MVP
> Windows Vista/2003/XP/2000 Consulting
> Device and Filesystem Drivers
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com

Gary
Thu Jan 05 11:10:33 CST 2006

Why do you need it turned off? Given that it is always set when one calls
BUILD I would say that thousands of drivers have been built with nary a
problem, and I also assume that you are havinga problem and have focused on
this as the root cause. So, again, can you state, explcitly why you think
/hotpatch is causing you a problem?

--
The personal opinion of
Gary G. Litte

"RossettoeCioccolato" <gmgarner@newsgroup.nospam> wrote in message
news:OSNUpUdEGHA.140@TK2MSFTNGP12.phx.gbl...
> Mark,
>
> Thanks for clarifying this. I thought that this was a Microsoft issue to
> begin with; and a pretty nasty bug in my opinion. Perhaps there are some
> restricted circumstances where the benefits of hot patching outweigh the
> inherent security risks. But I don't see why this switch should be turned
> on by default.
>
> Once again, would someone from Microsoft please explain how to turn this
> switch off within the DDK build environment?
>
> Regards,
>
> George.
>
> "Mark Roddy" <markr@hollistech.com> schrieb im Newsbeitrag
> news:015pr1tikav8opvfghrb7krijqtlro6sm8@4ax.com...
>> On Wed, 04 Jan 2006 20:06:37 GMT, jeffm@online.microsoft.com (Jeff
>> McCashland [MSFT]) wrote:
>>
>>>George,
>>>
>>>For that information, I believe you will need to ask the DDKBUILD vendor.
>>>
>>>Try http://www.hollistech.com/.
>>>
>>>Thanks,
>>>[MSFT] Jeff McCashland
>>>jeffm@online.microsoft.com
>>>
>>>This posting is provided "AS IS" with no warranties, and confers no
>>>rights.
>>
>> I don't qualify as a vendor here, for that I would have to actually
>> vend something :-)
>>
>> I give up what the heck is '/hotpatch'? I don't find this listed as a
>> parameter for build. Nor is it mentioned anywhere in the ddk docs.
>>
>> Ah - I see it is a compiler flag. Its use is undocumented in the DDK
>> and its support is some even more undocumented nonsense buried deep
>> within the build support files. Hmmm.. perhaps the OP ought to ask the
>> vendor of build about that?
>>
>> Looks to me like there is no way to turn it off on the command line so
>> no help from ddkbuild. You might try clobbering ERATTA_FLAGS in your
>> sources file. But now I am curious, why do you think you need to
>> disable this?
>>
>> I generally try not to muck too much with the builtin rules for driver
>> compilation/linking.
>>
>>
>>
>> =====================
>> Mark Roddy DDK MVP
>> Windows Vista/2003/XP/2000 Consulting
>> Device and Filesystem Drivers
>> Hollis Technology Solutions 603-321-1032
>> www.hollistech.com
>
>

David
Thu Jan 05 11:18:12 CST 2006

Why should hotpatch be a security risk? Those who want to patch can just
change the code and replicate it elsewhere as they have been doing for ages.
The hotpatching space just makes it easier to do it and allow it to be more
readily implemented, but it is not that much easier to do. The virus
writers who have to find instruction sequences to jump into by modifying a
return address or to patch in memory code do so much work at the machine
code level that it is not that much effort regardless of the hotpatch area.

"RossettoeCioccolato" <gmgarner@newsgroup.nospam> wrote in message
news:OSNUpUdEGHA.140@TK2MSFTNGP12.phx.gbl...
> Mark,
>
> Thanks for clarifying this. I thought that this was a Microsoft issue to
> begin with; and a pretty nasty bug in my opinion. Perhaps there are some
> restricted circumstances where the benefits of hot patching outweigh the
> inherent security risks. But I don't see why this switch should be turned
> on by default.
>
> Once again, would someone from Microsoft please explain how to turn this
> switch off within the DDK build environment?
>
> Regards,
>
> George.
>
> "Mark Roddy" <markr@hollistech.com> schrieb im Newsbeitrag
> news:015pr1tikav8opvfghrb7krijqtlro6sm8@4ax.com...
>> On Wed, 04 Jan 2006 20:06:37 GMT, jeffm@online.microsoft.com (Jeff
>> McCashland [MSFT]) wrote:
>>
>>>George,
>>>
>>>For that information, I believe you will need to ask the DDKBUILD vendor.
>>>
>>>Try http://www.hollistech.com/.
>>>
>>>Thanks,
>>>[MSFT] Jeff McCashland
>>>jeffm@online.microsoft.com
>>>
>>>This posting is provided "AS IS" with no warranties, and confers no
>>>rights.
>>
>> I don't qualify as a vendor here, for that I would have to actually
>> vend something :-)
>>
>> I give up what the heck is '/hotpatch'? I don't find this listed as a
>> parameter for build. Nor is it mentioned anywhere in the ddk docs.
>>
>> Ah - I see it is a compiler flag. Its use is undocumented in the DDK
>> and its support is some even more undocumented nonsense buried deep
>> within the build support files. Hmmm.. perhaps the OP ought to ask the
>> vendor of build about that?
>>
>> Looks to me like there is no way to turn it off on the command line so
>> no help from ddkbuild. You might try clobbering ERATTA_FLAGS in your
>> sources file. But now I am curious, why do you think you need to
>> disable this?
>>
>> I generally try not to muck too much with the builtin rules for driver
>> compilation/linking.
>>
>>
>>
>> =====================
>> Mark Roddy DDK MVP
>> Windows Vista/2003/XP/2000 Consulting
>> Device and Filesystem Drivers
>> Hollis Technology Solutions 603-321-1032
>> www.hollistech.com
>
>

jeffm
Thu Jan 05 12:42:34 CST 2006

------=_NextPart_0001_3CA0805A
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Mark,

Thanks for the clarification. I see this switch is set in a
platform-specific include file as ERATTA_FLAGS. You're probably correct
that clearing this variable in the sources file would do the trick.

George,

There is no supported or documented method to turn this switch off. Why is
there a need to do so, and in what way do you feel this is a bug?

Thanks,
[MSFT] Jeff McCashland
jeffm@online.microsoft.com

This posting is provided "AS IS" with no warranties, and confers no rights.
------=_NextPart_0001_3CA0805A
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 Mark,
\par
\par Thanks for the clarification. I see this switch is set in a platform-specific include file as ERATTA_FLAGS. You're probably correct that clearing this variable in the sources file would do the trick.
\par
\par George,
\par
\par There is no supported or documented method to turn this switch off. Why is there a need to do so, and in what way do you feel this is a bug?
\par
\par Thanks,
\par [MSFT] Jeff McCashland
\par jeffm@online.microsoft.com
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par
\par }
------=_NextPart_0001_3CA0805A--

RossettoeCioccolato
Thu Jan 05 16:41:15 CST 2006

Jeff,

> You're probably correct
> that clearing this variable in the sources file would do the trick. <

Apparently not. I tried the following in the sources file:

ERATTA_FLAGS=

But I still get the following in the build log:

cl -nologo -Ii386\ -I. -IH:\WINDDK\3790~1.183\\inc\mfc42 -I../include -Iobjchk_wnet_x86\i386
-IH:\WINDDK\3790~1.183\\inc\wnet -IH:\WINDDK\3790~1.183\\inc\wnet -IH:\WINDDK\3790~1.183\\inc\ddk\wnet
-IH:\WINDDK\3790~1.183\\inc\ddk\wdm\wnet -IH:\WINDDK\3790~1.183\\inc\crt -D_X86_=1
-Di386=1 -DSTD_CALL -DCONDITION_HANDLING=1 -DNT_INST=0 -DWIN32=100 -D_NT1X_=100
-DWINNT=1 -D_WIN32_WINNT=0x0502
INVER=0x0502 -D_WIN32_IE=0x0603 -DWIN32_LEAN_AND_MEAN=1 -DDEVL=1 -DDBG=1
-D__BUILDMACHINE__=WinDDK -DFPO=0 -DNDEBUG -D_DLL=1 /c /Zl /Zp8 /Gy
/Gm- -cbstring /W3 /WX /Gz /GX- /GR- /GF /GS /G6 /Ze /Gi- /QIfdiv-
/hotpatch -Z7 /Od /Oi /Oy- -FIH:\WINDDK\3790~1.183\\inc\wnet\warning.h
.\init.cpp .\xxxxxx.cpp

Or do I have to do something else?

> Why is there a need to do so. <

Obviously detours style hooks do have some security implications. There are
doubtless cases where the benefits outweigh the risks (mission critical
servers, etc.) but that is the exception not the rule. This particular
driver is a security application that will load on demand, be active for a
couple of minutes and then unload. Hot patching has no perceptible benefit
in this case and the risk that someone will try to exploit this "feature" is
particularly high. Of course, there are other ways to subvert a driver, as
some others have suggested. However, to use an analogy from every day life,
it is the difference between having your car stolen because someone jimmied
the lock and having it stolen because you left the keys in the ignition and
the car running at the convenience store. In either case your car is
stolen. But in the first case people think that you are a hapless victem.
In the latter case people think that you are an idiot who got what he
deserved.

> ... and in what way do you feel this is a bug? <

You have an undocumented feature with significant security implications that
is silently turned on by default even though it is only useful in a
restricted number of cases and there appears to be no way to turn it off.
Now what exactly would you call that?

Regards,

George.

Don
Thu Jan 05 17:31:21 CST 2006


"RossettoeCioccolato" <gmgarner@newsgroup.nospam> wrote in message
> Obviously detours style hooks do have some security implications. There
> are doubtless cases where the benefits outweigh the risks (mission
> critical servers, etc.) but that is the exception not the rule. This
> particular driver is a security application that will load on demand, be
> active for a couple of minutes and then unload. Hot patching has no
> perceptible benefit in this case and the risk that someone will try to
> exploit this "feature" is particularly high. Of course, there are other
> ways to subvert a driver, as some others have suggested. However, to use
> an analogy from every day life, it is the difference between having your
> car stolen because someone jimmied the lock and having it stolen because
> you left the keys in the ignition and the car running at the convenience
> store. In either case your car is stolen. But in the first case people
> think that you are a hapless victem. In the latter case people think that
> you are an idiot who got what he deserved.
>
>> ... and in what way do you feel this is a bug? <
>
> You have an undocumented feature with significant security implications
> that is silently turned on by default even though it is only useful in a
> restricted number of cases and there appears to be no way to turn it off.
> Now what exactly would you call that?

How is this a significant security problem? The compiler is spitting out a
few nops that allow for patching at the begining of a function without
having to overwrite real code.

The security is the same, someone trying to alter your driver still has to
bypass the write protection and in 64 bit the modification checks, then put
in their code. Compared with say grabing the driver object and changing
the IRP vector this is a lot of work. If the hot patch nop's are not
present, there is a miniscule additional piece of work to do this by
replacing the instructions that are there.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

jeffm
Fri Jan 06 12:46:02 CST 2006

------=_NextPart_0001_00CCA4BB
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Don,
Thanks for the clarification. I'll look into this further, but it sounds
like the switch doesn't enable or allow hotpatching, but rather protects
code, The VS 2005 docs say that it merely "ensures that [the] first
instruction of each function is two bytes". We're using it as part of our
security initiatives to reduce reboots when applying security patches.

for more info see:
http://www.microsoft.com/technet/security/topics/patchmanagement/patchmanage
ment.mspx


George,
A close examination of i386mk.inc and a little testing shows that adding:

LKG6COMPILER=

to your sources will suppress the switch. Or you could simply remove it
from i386mk.inc. I don't know what other effects the LKG6COMPILER option
might have, and either of these methods would be supported by Microsoft.

Thanks,
[MSFT] Jeff McCashland
jeffm@online.microsoft.com

This posting is provided "AS IS" with no warranties, and confers no rights.




------=_NextPart_0001_00CCA4BB
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 Don,
\par Thanks for the clarification. I'll look into this further, but it sounds like the switch doesn't enable or allow hotpatching, but rather protects code, The VS 2005 docs say that it merely "ensures that [the] first instruction of each function is two bytes". We're using it as part of our security initiatives to reduce reboots when applying security patches.
\par
\par for more info see:
\par http://www.microsoft.com/technet/security/topics/patchmanagement/patchmanagement.mspx
\par
\par
\par George,
\par A close examination of i386mk.inc and a little testing shows that adding:
\par
\par LKG6COMPILER=
\par
\par to your sources will suppress the switch. Or you could simply remove it from i386mk.inc. I don't know what other effects the LKG6COMPILER option might have, and either of these methods would be supported by Microsoft.
\par
\par Thanks,
\par [MSFT] Jeff McCashland
\par jeffm@online.microsoft.com
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par
\par
\par
\par
\par
\par }
------=_NextPart_0001_00CCA4BB--

RossettoeCioccolato
Fri Jan 20 15:02:26 CST 2006

Jeff,


> to your sources will suppress the switch. Or you could simply remove it
> from i386mk.inc.

Seems like this is the better approach. The /functionpadmin:5 also needs to
be suppressed/commented out. This is also a problem with amd64 and ia64
builds where the solution is similar. In the future please provide a way
to disable these switches, or better, to only enable them when requested.

These switches add more than just two bytes, btw.

Regards,

George.