suppressing /hotpatch in ddk build environment

Discussion in 'Windows Vista Drivers' started by RossettoeCioccolato, Jan 3, 2006.

  1. 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?



    RossettoeCioccolato, Jan 3, 2006
    1. Advertisements

  2. George,

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


    [MSFT] Jeff McCashland

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Jeff McCashland [MSFT], Jan 4, 2006
    1. Advertisements

  3. RossettoeCioccolato

    Mark Roddy Guest

    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

    Mark Roddy DDK MVP
    Windows Vista/2003/XP/2000 Consulting
    Device and Filesystem Drivers
    Hollis Technology Solutions 603-321-1032
    Mark Roddy, Jan 5, 2006
  4. 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?



    RossettoeCioccolato, Jan 5, 2006
  5. 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

    Gary G. Little, Jan 5, 2006
  6. 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.

    David J. Craig, Jan 5, 2006
  7. 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.


    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?

    [MSFT] Jeff McCashland

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Jeff McCashland [MSFT], Jan 5, 2006
  8. Jeff,
    Apparently not. I tried the following in the sources file:


    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
    -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?
    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
    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?


    RossettoeCioccolato, Jan 5, 2006
  9. RossettoeCioccolato

    Don Burn Guest

    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, Jan 5, 2006
  10. 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:

    A close examination of and a little testing shows that adding:


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

    [MSFT] Jeff McCashland

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Jeff McCashland [MSFT], Jan 6, 2006
  11. Jeff,

    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.


    RossettoeCioccolato, Jan 20, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.