PROT_EXEC mmap/mprotect, i386 PAE + NX broken, x86-64 2.6.17-rc2

[Alistair John Strachan]

Hi,

Just a heads up that WINE seems to suffer from breakage if executed as a 32bit 
binary on an x86-64 kernel as of 2.6.17-rc, because (according to Andi Kleen) 
i386 NX is now enabled by default, and on x86-64 i386 behaves like a PAE 
enabled i386 kernel when performing IA32 emulation.

I've attached the entire thread for reference, as unfortunately I do not have 
the time to debug this problem, but thought that probably one of you would 
like to know.

Thread is also available to read here:

http://lkml.org/lkml/2006/4/21/99

Andi suspects that WINE is not making one of its mappings PROT_EXEC which 
causes a fault with NX enabled.

[Marcus Meissner]

On Sat, Apr 22, 2006 at 04:30:24AM +0100, Alistair John Strachan wrote:
> Hi,
>
> Just a heads up that WINE seems to suffer from breakage if executed as a 32bit 
> binary on an x86-64 kernel as of 2.6.17-rc, because (according to Andi Kleen) 
> i386 NX is now enabled by default, and on x86-64 i386 behaves like a PAE 
> enabled i386 kernel when performing IA32 emulation.
>
> I've attached the entire thread for reference, as unfortunately I do not have 
> the time to debug this problem, but thought that probably one of you would 
> like to know.
>
> Thread is also available to read here:
>
> http://lkml.org/lkml/2006/4/21/99
>
> Andi suspects that WINE is not making one of its mappings PROT_EXEC which 
> causes a fault with NX enabled.

Well, in your case it seems to be the main executable, since it faults
at its very first instruction.
> [alistair] 11:17 [~/.wine/drive_c/Program Files/Warcraft III] wine war3.exe -opengl
> wine: Unhandled page fault on write access to 0x00495000 at address 0x495000 (thread 0009), starting debugger...
> =>1 0x00495000 EntryPoint in war3 (0x00495000)
>   2 0xf7f763ab wine_switch_to_stack+0x17 in libwine.so.1 (0xf7f763ab)
> 0x00495000 EntryPoint in war3: pushl    %eax

Please run with:
    WINEDEBUG=+virtual wine war3.exe -opengl

And look for the virtual entries in the vicinity of 495000.

Ciao, Marcus

[Alistair John Strachan]

On Saturday 22 April 2006 08:38, Marcus Meissner wrote:
[snip]
> Well, in your case it seems to be the main executable, since it faults
> at its very first instruction.

Maybe I'm just misunderstanding what you're saying here, but the problem is 
_not_ with the application I am attempting to run. It works flawlessly with 
an x86-64 kernel with noexec32=off, or 2.6.14.7 (where this is the default).
> > [alistair] 11:17 [~/.wine/drive_c/Program Files/Warcraft III] wine
> > war3.exe -opengl wine: Unhandled page fault on write access to 0x00495000
> > at address 0x495000 (thread 0009), starting debugger...
> >
> > =>1 0x00495000 EntryPoint in war3 (0x00495000)
> >   2 0xf7f763ab wine_switch_to_stack+0x17 in libwine.so.1 (0xf7f763ab)
> > 0x00495000 EntryPoint in war3: pushl    %eax
>
> Please run with:
>    WINEDEBUG=+virtual wine war3.exe -opengl
>
> And look for the virtual entries in the vicinity of 495000.

Can't see anything obvious. Here's the entire trace:

http://devzero.co.uk/~alistair/wine/virtual.log

[Marcus Meissner]

On Sat, Apr 22, 2006 at 09:43:43AM +0100, Alistair John Strachan wrote:
> On Saturday 22 April 2006 08:38, Marcus Meissner wrote:
> [snip]
> > Well, in your case it seems to be the main executable, since it faults
> > at its very first instruction.
>
> Maybe I'm just misunderstanding what you're saying here, but the problem is 
> _not_ with the application I am attempting to run. It works flawlessly with 
> an x86-64 kernel with noexec32=off, or 2.6.14.7 (where this is the default).

It is a WINE problem :)
> > > [alistair] 11:17 [~/.wine/drive_c/Program Files/Warcraft III] wine
> > > war3.exe -opengl wine: Unhandled page fault on write access to 0x00495000
> > > at address 0x495000 (thread 0009), starting debugger...
> > >
> > > =>1 0x00495000 EntryPoint in war3 (0x00495000)
> > >   2 0xf7f763ab wine_switch_to_stack+0x17 in libwine.so.1 (0xf7f763ab)
> > > 0x00495000 EntryPoint in war3: pushl    %eax
> >
> > Please run with:
> >    WINEDEBUG=+virtual wine war3.exe -opengl
> > And look for the virtual entries in the vicinity of 495000.
>
> Can't see anything obvious. Here's the entire trace:
> http://devzero.co.uk/~alistair/wine/virtual.log

Here is the culprit:

trace:virtual:VIRTUAL_SetProt 0x462000-0x4e7fff c-rW-
trace:virtual:VIRTUAL_DumpView View: 0x400000 - 0x57bfff (anonymous)
trace:virtual:VIRTUAL_DumpView       0x400000 - 0x400fff c-r--
trace:virtual:VIRTUAL_DumpView       0x401000 - 0x449fff c-r-x
trace:virtual:VIRTUAL_DumpView       0x44a000 - 0x57bfff c-rW-

This covers the 0x00495000 address. Note that the area lacks the x-bit.

What is happening is likely the copy protection. The original loader is
likely executable, but the copyprotection decrypts the code in a datasection
and then executes it.

Could you please do:
    winedump dump -x war3.exe
and put it somewhere/attach it here?

Ciao, Marcus

[Alistair John Strachan]

On Saturday 22 April 2006 10:09, Marcus Meissner wrote:
[snip]
> > > > [alistair] 11:17 [~/.wine/drive_c/Program Files/Warcraft III] wine
> > > > war3.exe -opengl wine: Unhandled page fault on write access to
> > > > 0x00495000 at address 0x495000 (thread 0009), starting debugger...
> > > >
> > > > =>1 0x00495000 EntryPoint in war3 (0x00495000)
> > > >   2 0xf7f763ab wine_switch_to_stack+0x17 in libwine.so.1 (0xf7f763ab)
> > > > 0x00495000 EntryPoint in war3: pushl    %eax
> > >
> > > Please run with:
> > >    WINEDEBUG=+virtual wine war3.exe -opengl
> > > And look for the virtual entries in the vicinity of 495000.
> >
> > Can't see anything obvious. Here's the entire trace:
> > http://devzero.co.uk/~alistair/wine/virtual.log
>
> Here is the culprit:
>
> trace:virtual:VIRTUAL_SetProt 0x462000-0x4e7fff c-rW-
> trace:virtual:VIRTUAL_DumpView View: 0x400000 - 0x57bfff (anonymous)
> trace:virtual:VIRTUAL_DumpView       0x400000 - 0x400fff c-r--
> trace:virtual:VIRTUAL_DumpView       0x401000 - 0x449fff c-r-x
> trace:virtual:VIRTUAL_DumpView       0x44a000 - 0x57bfff c-rW-
>
> This covers the 0x00495000 address. Note that the area lacks the x-bit.
>
> What is happening is likely the copy protection. The original loader is
> likely executable, but the copyprotection decrypts the code in a
> datasection and then executes it.

Well, I'm using a "modified" game executable which does not check for the 
presence of a CD. However, it hooks into the original game executable so that 
the game can validate itself. Alas, it's probably not the more pure win32 
application known to man..
> Could you please do:
>    winedump dump -x war3.exe
> and put it somewhere/attach it here?

Certainly, find it here (261K):

http://devzero.co.uk/~alistair/wine/dump.log

[Marcus Meissner]

> > > http://devzero.co.uk/~alistair/wine/virtual.log
> >
> > Here is the culprit:
> >
> > trace:virtual:VIRTUAL_SetProt 0x462000-0x4e7fff c-rW-
> > trace:virtual:VIRTUAL_DumpView View: 0x400000 - 0x57bfff (anonymous)
> > trace:virtual:VIRTUAL_DumpView       0x400000 - 0x400fff c-r--
> > trace:virtual:VIRTUAL_DumpView       0x401000 - 0x449fff c-r-x
> > trace:virtual:VIRTUAL_DumpView       0x44a000 - 0x57bfff c-rW-
> >
> > This covers the 0x00495000 address. Note that the area lacks the x-bit.
> >
> > What is happening is likely the copy protection. The original loader is
> > likely executable, but the copyprotection decrypts the code in a
> > datasection and then executes it.
>
> Well, I'm using a "modified" game executable which does not check for the 
> presence of a CD. However, it hooks into the original game executable so that 
> the game can validate itself. Alas, it's probably not the more pure win32 
> application known to man..
> > Could you please do:
> >    winedump dump -x war3.exe
> > and put it somewhere/attach it here?
>
> Certainly, find it here (261K):
>
> http://devzero.co.uk/~alistair/wine/dump.log

This is the section with the entry point in:

04 .iyhivx    VirtSize: 548864    VirtAddr:  401408   0x00062000
    raw data offs: 356352   raw data size: 548864
    relocation offs: 0         relocations:   0
    line # offs:     0         line #'s:      0
    characteristics: 0xc0000040
      INITIALIZED_DATA  MEM_READ  MEM_WRITE

It is missing the "MEM_EXECUTE" flag.

Try this patch:

Index: dlls/ntdll/virtual.c
===================================================================
RCS file: /home/wine/wine/dlls/ntdll/virtual.c,v
retrieving revision 1.88
diff -u -r1.88 virtual.c
--- dlls/ntdll/virtual.c	8 Apr 2006 18:13:41 -0000	1.88
+++ dlls/ntdll/virtual.c	22 Apr 2006 12:53:46 -0000
@@ -1072,6 +1072,12 @@
         if (sec->Characteristics & IMAGE_SCN_MEM_READ)    vprot |= VPROT_READ;
         if (sec->Characteristics & IMAGE_SCN_MEM_WRITE)   vprot |= VPROT_READ|VPROT_WRITECOPY;
         if (sec->Characteristics & IMAGE_SCN_MEM_EXECUTE) vprot |= VPROT_EXEC;
+
+	/* Dumb game crack let the AOEP point into a data section. Adjust. */
+        if (	(nt->OptionalHeader.AddressOfEntryPoint >= sec->VirtualAddress) &&
+        	(nt->OptionalHeader.AddressOfEntryPoint < sec->VirtualAddress + size)
+	)
+		vprot |= VPROT_EXEC;
         VIRTUAL_SetProt( view, ptr + sec->VirtualAddress, size, vprot );
     }

Ciao, Marcus

[Alistair John Strachan]

On Saturday 22 April 2006 13:54, Marcus Meissner wrote:
> > > > http://devzero.co.uk/~alistair/wine/virtual.log
> > >
> > > Here is the culprit:
> > >
> > > trace:virtual:VIRTUAL_SetProt 0x462000-0x4e7fff c-rW-
> > > trace:virtual:VIRTUAL_DumpView View: 0x400000 - 0x57bfff (anonymous)
> > > trace:virtual:VIRTUAL_DumpView       0x400000 - 0x400fff c-r--
> > > trace:virtual:VIRTUAL_DumpView       0x401000 - 0x449fff c-r-x
> > > trace:virtual:VIRTUAL_DumpView       0x44a000 - 0x57bfff c-rW-
> > >
> > > This covers the 0x00495000 address. Note that the area lacks the x-bit.
> > >
> > > What is happening is likely the copy protection. The original loader is
> > > likely executable, but the copyprotection decrypts the code in a
> > > datasection and then executes it.
> >
> > Well, I'm using a "modified" game executable which does not check for the
> > presence of a CD. However, it hooks into the original game executable so
> > that the game can validate itself. Alas, it's probably not the more pure
> > win32 application known to man..
> > > Could you please do:
> > >    winedump dump -x war3.exe
> > > and put it somewhere/attach it here?
> >
> > Certainly, find it here (261K):
> >
> > http://devzero.co.uk/~alistair/wine/dump.log
>
> This is the section with the entry point in:
>
> 04 .iyhivx    VirtSize: 548864    VirtAddr:  401408   0x00062000
>     raw data offs: 356352   raw data size: 548864
>     relocation offs: 0         relocations:   0
>     line # offs:     0         line #'s:      0
>     characteristics: 0xc0000040
>       INITIALIZED_DATA  MEM_READ  MEM_WRITE
>
> It is missing the "MEM_EXECUTE" flag.

The patch did the trick. Thanks for taking the time to debug this.

[Jesse Allen]

On 4/22/06, Marcus Meissner  wrote:
> > Certainly, find it here (261K):
> >
> > http://devzero.co.uk/~alistair/wine/dump.log
>
> This is the section with the entry point in:
>
> 04 .iyhivx    VirtSize: 548864    VirtAddr:  401408   0x00062000
>     raw data offs: 356352   raw data size: 548864
>     relocation offs: 0         relocations:   0
>     line # offs:     0         line #'s:      0
>     characteristics: 0xc0000040
>       INITIALIZED_DATA  MEM_READ  MEM_WRITE
>
> It is missing the "MEM_EXECUTE" flag.
>
> Try this patch:
> Index: dlls/ntdll/virtual.c
>
> RCS file: /home/wine/wine/dlls/ntdll/virtual.c,v
> retrieving revision 1.88
> diff -u -r1.88 virtual.c
> --- dlls/ntdll/virtual.c        8 Apr 2006 18:13:41 -0000       1.88
> +++ dlls/ntdll/virtual.c        22 Apr 2006 12:53:46 -0000
> @@ -1072,6 +1072,12 @@
>          if (sec->Characteristics & IMAGE_SCN_MEM_READ)    vprot |= VPROT_READ;
>          if (sec->Characteristics & IMAGE_SCN_MEM_WRITE)   vprot |= VPROT_READ|VPROT_WRITECOPY;
>          if (sec->Characteristics & IMAGE_SCN_MEM_EXECUTE) vprot |= VPROT_EXEC;
> -
> -
>   /* Dumb game crack let the AOEP point into a data section. Adjust. */
> -
>    if (   (nt->OptionalHeader.AddressOfEntryPoint >= sec->VirtualAddress) &&
> -
>           (nt->OptionalHeader.AddressOfEntryPoint < sec->VirtualAddress + size)
> -
>   )
> -
>           vprot |= VPROT_EXEC;
>    VIRTUAL_SetProt( view, ptr + sec->VirtualAddress, size, vprot );
> }
>
> Ciao, Marcus

Here's the unmodified executable:

ftp://resnet.dnip.net/dump.txt

It has MEM_EXECUTE correctly set. I think that loader should be
considered buggy.

Jesse

[Alistair John Strachan]

On Saturday 22 April 2006 18:38, Jesse Allen wrote:
[snip]
> It has MEM_EXECUTE correctly set. I think that loader should be
> considered buggy.

This executable works on Windows, therefore it should work in Wine. It's 
really that simple. If Windows doesn't enforce DEP/NX, neither should Wine. 
Or, at the very least, it should be configurable.

[Jesse Allen]

On 4/22/06, Alistair John Strachan  wrote:
> On Saturday 22 April 2006 18:38, Jesse Allen wrote:
> [snip]
> > It has MEM_EXECUTE correctly set. I think that loader should be
> > considered buggy.
>
> This executable works on Windows, therefore it should work in Wine. It's
> really that simple. If Windows doesn't enforce DEP/NX, neither should Wine.
> Or, at the very least, it should be configurable.

What about x86-64 versions of Windows? I think it allows you to turn
it on and off, but we should find out. I still think the modified
executable is buggy, but if Windows does it, we could do it too.

Jesse

[Alistair John Strachan]

On Sunday 23 April 2006 16:35, Jesse Allen wrote:
> On 4/22/06, Alistair John Strachan  wrote:
> > On Saturday 22 April 2006 18:38, Jesse Allen wrote:
> > [snip]
> > > It has MEM_EXECUTE correctly set. I think that loader should be
> > > considered buggy.
> >
> > This executable works on Windows, therefore it should work in Wine. It's
> > really that simple. If Windows doesn't enforce DEP/NX, neither should
> > Wine. Or, at the very least, it should be configurable.
>
> What about x86-64 versions of Windows? I think it allows you to turn
> it on and off, but we should find out. I still think the modified
> executable is buggy, but if Windows does it, we could do it too.

My *guess* is that Windows x64 Edition will enforce DEP/NX for 64bit 
applications, but will do the same as XP SP2 for 32bit applications. That is, 
for 32bit applications, you can choose to enforce DEP/NX, and "whitelist" 
applications (selectively disabling DEP/NX), or have _only_ Windows component 
DLLs secured by DEP/NX (the default).

Linux, until 2.6.17-rc, also did this. Andi Kleen suggested on LKML that there 
are userspace tools for Linux which allow NX to be disabled per-binary at 
runtime, but I suspect such utilities would require privileges. It would be 
suboptimal to mandate their use with Wine.

[Jesse Allen]

On 4/23/06, Alistair John Strachan  wrote:
> My *guess* is that Windows x64 Edition will enforce DEP/NX for 64bit
> applications, but will do the same as XP SP2 for 32bit applications. That is,
> for 32bit applications, you can choose to enforce DEP/NX, and "whitelist"
> applications (selectively disabling DEP/NX), or have _only_ Windows component
> DLLs secured by DEP/NX (the default).

Ah, ok now I remember.
> Linux, until 2.6.17-rc, also did this. Andi Kleen suggested on LKML that there
> are userspace tools for Linux which allow NX to be disabled per-binary at
> runtime, but I suspect such utilities would require privileges. It would be
> suboptimal to mandate their use with Wine.

Well I think that it would be a better policy to have such tools
control the setting. It already seems to be out of the norm, seeing it
was modified. I don't think it will happen often, unless we can find
an actual common program. Now if it's safe to mark the entry point of
an executable MEM_EXECUTE -- which probably is -- then I'm fine with
that too.

Jesse

[Mike Hearn]

On Sat, 22 Apr 2006 11:12:06 +0100, Alistair John Strachan wrote:
> Well, I'm using a "modified" game executable which does not check for the 
> presence of a CD. However, it hooks into the original game executable so that 
> the game can validate itself. Alas, it's probably not the more pure win32 
> application known to man..

Does it work if you use a legit copy?
> http://devzero.co.uk/~alistair/wine/dump.log

It appears to be the .iyhivx section, it's not marked MEM_EXECUTE and
googling it shows people reporting backtraces with offsets just into it
... so looks like Marcus is correct.

In which case this is really a Warcraft bug. But as NX is not really
enforced on Windows I guess we need to fix this in Wine by always marking
sections executable or something. Well it's easy to do but I dunno what AJ
wants and he just went on holiday. For now just hack dlls/ntdll/loader.c
to always mark sections as executable.

thanks -mike

[Jesse Allen]

On 4/22/06, Mike Hearn  wrote:
> On Sat, 22 Apr 2006 11:12:06 +0100, Alistair John Strachan wrote:
> > Well, I'm using a "modified" game executable which does not check for the
> > presence of a CD. However, it hooks into the original game executable so that
> > the game can validate itself. Alas, it's probably not the more pure win32
> > application known to man..
>
> Does it work if you use a legit copy?
> > http://devzero.co.uk/~alistair/wine/dump.log
>
> It appears to be the .iyhivx section, it's not marked MEM_EXECUTE and
> googling it shows people reporting backtraces with offsets just into it
> ... so looks like Marcus is correct.
>
> In which case this is really a Warcraft bug. But as NX is not really
> enforced on Windows I guess we need to fix this in Wine by always marking
> sections executable or something. Well it's easy to do but I dunno what AJ
> wants and he just went on holiday. For now just hack dlls/ntdll/loader.c
> to always mark sections as executable.
>
> thanks -mike

Doesn't Windows x86-64 enforce NX?

Jesse

[Tom Spear (Dustin Booker, Dustin Navea)]

Jesse Allen wrote:
> On 4/22/06, Mike Hearn  wrote:
> > On Sat, 22 Apr 2006 11:12:06 +0100, Alistair John Strachan wrote:
> > > Well, I'm using a "modified" game executable which does not check for the
> > > presence of a CD. However, it hooks into the original game executable so that
> > > the game can validate itself. Alas, it's probably not the more pure win32
> > > application known to man..
> >
> > Does it work if you use a legit copy?
> > > http://devzero.co.uk/~alistair/wine/dump.log
> >
> > It appears to be the .iyhivx section, it's not marked MEM_EXECUTE and
> > googling it shows people reporting backtraces with offsets just into it
> > ... so looks like Marcus is correct.
> >
> > In which case this is really a Warcraft bug. But as NX is not really
> > enforced on Windows I guess we need to fix this in Wine by always marking
> > sections executable or something. Well it's easy to do but I dunno what AJ
> > wants and he just went on holiday. For now just hack dlls/ntdll/loader.c
> > to always mark sections as executable.
> >
> > thanks -mike
>
> Doesn't Windows x86-64 enforce NX?
>
> Jesse

Only if you are talking about hardware based NX, but that is different 
from what is going on here.  The kernel has software-based NX enabled by 
default now and that is what is affecting this loader..

[Marcus Meissner]

On Sun, Apr 23, 2006 at 11:25:09AM -0500, Tom Spear (Dustin Booker, Dustin Navea) wrote:
...
> > Jesse
>
> Only if you are talking about hardware based NX, but that is different 
> from what is going on here.  The kernel has software-based NX enabled by 
> default now and that is what is affecting this loader..

The mainline Linux kernel has only hardware NX support, which x86_64 natively
supports.

Software NX (via CS selector) is only in Redhats execshield patch.

Ciao, Marcus

[Jesse Allen]

On 4/22/06, Alistair John Strachan  wrote:
> On Saturday 22 April 2006 10:09, Marcus Meissner wrote:
> > Here is the culprit:
> >
> > trace:virtual:VIRTUAL_SetProt 0x462000-0x4e7fff c-rW-
> > trace:virtual:VIRTUAL_DumpView View: 0x400000 - 0x57bfff (anonymous)
> > trace:virtual:VIRTUAL_DumpView       0x400000 - 0x400fff c-r--
> > trace:virtual:VIRTUAL_DumpView       0x401000 - 0x449fff c-r-x
> > trace:virtual:VIRTUAL_DumpView       0x44a000 - 0x57bfff c-rW-
> >
> > This covers the 0x00495000 address. Note that the area lacks the x-bit.
> >
> > What is happening is likely the copy protection. The original loader is
> > likely executable, but the copyprotection decrypts the code in a
> > datasection and then executes it.
>
> Well, I'm using a "modified" game executable which does not check for the
> presence of a CD. However, it hooks into the original game executable so that
> the game can validate itself. Alas, it's probably not the more pure win32
> application known to man..

Do you mean you're using a loader? Please try to recreate without the
loader. Loaders are known to be buggy -- even on x86 architechure.

Jesse