Date: Tue, 8 Jun 2004 05:20:55 -0400
From: Jakub Jelinek <jakub@redhat.com>
To: Arjan van de Ven <arjanv@redhat.com>
Cc: Mike McCormack <mike@codeweavers.com>, Ingo Molnar <mingo@elte.hu>,
       linux-kernel@vger.kernel.org
Subject: Re: WINE + NX (No eXecute) support for x86, 2.6.7-rc2-bk2
Message-ID: <20040608092055.GX4736@devserv.devel.redhat.com>
Reply-To: Jakub Jelinek <jakub@redhat.com>
References: <40C2B51C.9030203@codeweavers.com> <20040606052615.GA14988@elte.hu> <40C2D5F4.4020803@codeweavers.com> <1086507140.2810.0.camel@laptop.fenrus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1086507140.2810.0.camel@laptop.fenrus.com>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2238
Lines: 47

On Sun, Jun 06, 2004 at 09:32:21AM +0200, Arjan van de Ven wrote:
> On Sun, 2004-06-06 at 10:29, Mike McCormack wrote:
> > Hi Ingo,
> > 
> > Ingo Molnar wrote:
> > 
> > > there are multiple methods in FC1 to turn this off:
> > > 
> > > - FC1 has PT_GNU_STACK support and all binaries that have no
> > >   PT_GNU_STACK program header will have the stock Linux VM layout. 
> > >   (including executable stack/heap) So by stripping the PT_GNU_STACK 
> > >   header from the wine binary you get this effect.
> > 
> > As far as we can tell, this alone does not stop the kernel from loading 
> > stuff at the addresses we need.  Even without PT_GNU_STACK ld-linux.so.2 
> > and libc are loaded below 0x01000000, which is the region that Wine 
> > assumes is free.  I think this may be due to prelinking...
> 
> that is prelink yes, not the kernel execshield.

But prelink only allocates in the area below executable if
/proc/sys/kernel/exec-shield exist (and only for i386; there is also
--exec-shield/--no-exec-shield to override).

Really the most safe way for Wine is to create a PT_LOAD segment with
p_flags 0 covering the whole area below the executable.  The kernel first
maps the executable, then the dynamic linker, so no matter what address
are ld.so and shared libraries prelinked to, they will not be mapped to the
area Wine reserves.
Unfortunately, there is no easy way in ld to create the segment ATM,
see http://sources.redhat.com/ml/binutils/2003-12/msg00211.html
In current binutils, perhaps creating a special linker script from the
default on the fly and assigning segments there could work, but maybe
far easier would be to just create one allocated PT_LOAD segment somewhere
and using libelf change it's location and p_flags.

Making Wine a PIE is also a possible solution (at least in FC2 for
non-prelinked PIEs kernel doesn't honor ld.so's prelinked address), but
then you cannot be sure the kernel doesn't choose the addresses Wine wishes
to reserve while randomizing.

	Jakub
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/