inheriting exec-shield avoidance

[Peter Riocreux]

Mike McCormack <mike at codeweavers.com> writes:

> Hi Peter,
>
> I'm not familiar with the using "setarch i386" to solve the problem...
>
> I've also been working on the exec-shield problem over the last couple
> of days.  My solution is similar to Mike Hearn's approach, but faster
> and more compact, since it doesn't require loading of libc twice or
> static linking with glibc.  The idea is to use a staticly linked ELF
> object, reserve memory and then load the target dynamicly linked
> object.
>
> It seems to do what I want, but will require a patch or two to wine to
> use MAP_FIXED when mapping the first megabyte of address space, and to
> make sure newly forked processes are forked with it as the (pre)loader.
>
> I've attached the source code.  The idea is to run it like this:
>
> wld /home/mike/wine/loader/wine-pthread my.exe

Built and tried this out.

First up, I get two instances of the following:

unknown header type 6474E551

It makes the first load work, - giving the same result as the setarch
idea (I know (or at least I *think* I know) it is by a different
means), but it doesn't solve the inheritance/forking problem. I assume
that is what the patches you mention would do.

To make this a bit clearer, A creates children B then C. With setarch
or wld when exec-shield is ON, A loads, but B doesn't. With
exec-shield OFF, B loads, but C doesn't! I don't understand the
latter at all.

In case it is relevant, I suspect that the child processes are created
by a built-in scripting language engine.

Am open to trying out other things to get round the remaining part of
this.

Peter