This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Add support for the Win32 hook prologue (try 3)


On Friday 11 September 2009 00:27:00, Stefan Dösinger wrote:
> A number of Windows programs(Steam, Xfire and others) try to hook Win32 API 
> functions by replacing the first 5 bytes in the function. This causes 
> problems for Wine because the functions generated by gcc usually start with a 
> different opcode sequence than the one expected by these applications.
> 
> Starting with Windows XP SP2, Microsoft starts Win32 functions with this 
> sequence:
> 
> 8b ff		mov %edi, %edi
> 55		push %ebp
> 8b ec	mov %esp, %ebp
> 
> The attached patch implements a function attribute that allows Wine to request 
> the same 5 bytes at the beginning of a function.
> 
> I tested the testuite on x86_64-pc-linux-gnu.
> 

> +  /* This value is used for i386 targets and specifies if the function
> +   * should start with the hooking-friendly Win32 function prologue       */
> +  int msvc_prologue;

I have too comments:

As you said, these prologues are used for hot patching.  But, AFAIK, the
prologue alone won't cut it.  This prologue works together with 5 bytes of
slack before the function.  The idea is to be able to patch the 5 bytes
with a jump into anywhere in the 32-bit address space (while being
sure nothing is executing that bit of code), and then atomicaly replace
that 2 byte op with a jump to 5 bytes back.  Something like:

    nop                            |
    nop                            |
    nop                            |  hot patching
    nop                            |  support
    nop                            |
    mov    %edi,%edi               |   <-- function start
-----------------------------------+
    push   %ebp                    |
    mov    %esp,%ebp               |  frame setup
    sub    $0x18,%esp              |  locals, ...


If the new attribute doesn't add some assembly directive so that the
assembler/linker makes sure the slack is there, users of the attribute
have to do it manually themselves somehow.  Otherwise, if nothing adds
the nops, you may find that Steam, Xfire and others corrupt the end
of a previous function that is unfortunate enough to be placed where the
nops slack should be.  Did you consider this?
How is wine handling that?  It may be perhaps nice to mention
something about the needed slack in the documentation of the new
attribute.

Then the nit-pick comment: Isn't the attribute misnamed?  This is about win32
api hooking, not what MSFT's compiler/ide (MSVC) usually outputs for
prologues.  Why not naming it as something that aludes to that, instead of
(at least to me), implying that you're outputting the prologue MSVC usually
outputs (without the magic hooking support)?  In fact, MSFT may be adding
this hooking prologue by hand with assembly, not using the Visual C
compiler.  In fact, all your descriptions of the attribute mention
win32 api hooking, not MSVC.  Any of e.g., w32_hook_prologue,
ms_hook_prologue, ms_hot_patch_prologue, w32_hot_patch_prologue would
make sense to me.

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]