PROT_EXEC mmap/mprotect, i386 PAE + NX broken, x86-64 2.6.17-rc2
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. -- Cheers, Alistair. Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK.
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
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 -- Cheers, Alistair. Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK.
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
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 -- Cheers, Alistair. Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK.
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):
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
On Saturday 22 April 2006 13:54, 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..
Could you please do: winedump dump -x war3.exe and put it somewhere/attach it here?
Certainly, find it here (261K):
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. -- Cheers, Alistair. Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK.
On 4/22/06, Marcus Meissner <marcus(a)jet.franken.de> wrote:
Certainly, find it here (261K):
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
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. -- Cheers, Alistair. Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK.
On 4/22/06, Alistair John Strachan <s0348365(a)sms.ed.ac.uk> 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
On Sunday 23 April 2006 16:35, Jesse Allen wrote:
On 4/22/06, Alistair John Strachan <s0348365(a)sms.ed.ac.uk> 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. -- Cheers, Alistair. Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK.
On 4/23/06, Alistair John Strachan <s0348365(a)sms.ed.ac.uk> 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
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?
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
On 4/22/06, Mike Hearn <mike(a)plan99.net> 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?
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
Jesse Allen wrote:
On 4/22/06, Mike Hearn <mike(a)plan99.net> 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?
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..
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
On 4/22/06, Alistair John Strachan <s0348365(a)sms.ed.ac.uk> 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
participants (5)
-
Alistair John Strachan -
Jesse Allen -
Marcus Meissner -
Mike Hearn -
Tom Spear (Dustin Booker, Dustin Navea)