This is a follow-up on the thread on cemw
'Wine with ASS won't run stripped binaries' (see below)
With a 'kernel security patch', the default load address for modules
seems to be moved to 110000 address, to get the Wine modules in the way of
the Win32 normal load address (400000) and reportedly there is a very misleading
message
on relocation and stripped executables.
I have the following questions for the Linux specialists out there.
1) what are the chances of this patch to become the default in some near future ?
2) what could be the best way to solve such problem :
- if a PE module where preferred loadaddress = 0 gets an address below < 400000 hex,
print a
warning.
- force the load address ?
- other ?
Gerard
Here is a quote of the post of 'STiNG OF DEATH' on cemw :
>Yes, I found and fixed the problem. As opposed to being a complex
>memory problem, it was simply a case of me not R'ing the F'img
>manual... I had the kernel security patch installed that I
>was testing, and I was somehow working with a kernel with all the
>security options turned on. Part of the security patch is to
>reallocate stack space to prevent hackers playing with your
>executable stack space.
>
>I quote from the patch's diff file
>
> /* This decides where the kernel will search for a free chunk of vm
> * space during mmap's.
> */
>+#if defined(CONFIG_SECURE_STACK) && defined(CONFIG_BINFMT_ELF)
>+extern struct linux_binfmt elf_format;
>+#define TASK_UNMAPPED_BASE ( \
>+ current->binfmt == &elf_format && \
>+ !(current->flags & PF_STACKEXEC) \
>+ ? 0x00110000UL \
>+ : TASK_SIZE / 3 )
>+#else
> #define TASK_UNMAPPED_BASE (TASK_SIZE / 3)
>+#endif
>
>In other words, if secure stack is enabled, the unmapped base is
>moved. This has the possiblity to break WINE and many other programs.
