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
Date: Tue, 8 Jun 2004 05:20:55 -0400 [thread overview]
Message-ID: <20040608092055.GX4736@devserv.devel.redhat.com> (raw)
In-Reply-To: <1086507140.2810.0.camel@laptop.fenrus.com>
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
next prev parent reply other threads:[~2004-06-08 9:21 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-06 6:09 WINE + NX (No eXecute) support for x86, 2.6.7-rc2-bk2 Mike McCormack
2004-06-06 5:26 ` Ingo Molnar
2004-06-06 8:29 ` Mike McCormack
2004-06-06 7:32 ` Arjan van de Ven
2004-06-08 9:20 ` Jakub Jelinek [this message]
2004-06-08 11:15 ` Mike McCormack
2004-06-08 10:32 ` Ingo Molnar
2004-06-08 12:01 ` Mike McCormack
2004-06-09 1:40 ` John Reiser
2004-06-09 2:27 ` Paul Jackson
2004-06-06 7:32 ` Christoph Hellwig
2004-06-06 9:13 ` Mike McCormack
2004-06-06 8:10 ` Christoph Hellwig
2004-06-06 9:37 ` Mike McCormack
2004-06-06 8:39 ` Christoph Hellwig
2004-06-06 8:43 ` Christoph Hellwig
2004-06-06 10:20 ` Mike McCormack
2004-06-06 11:17 ` Felipe Alfaro Solana
2004-06-07 4:20 ` Horst von Brand
2004-06-07 14:19 ` Ingo Molnar
2004-06-08 21:50 ` Robert White
2004-06-08 21:57 ` Robert White
2004-06-09 16:53 ` Jesse Pollard
2004-06-09 20:53 ` Robert White
2004-06-10 13:35 ` Jesse Pollard
2004-06-10 21:13 ` Robert White
2004-06-11 9:50 ` Marc Bevand
2004-06-09 17:14 ` Jesper Juhl
2004-06-09 18:02 ` Evaldo Gardenali
2004-06-09 19:58 ` Felipe Alfaro Solana
2004-06-10 18:07 ` Stefanos Harhalakis
2004-06-06 11:38 ` David Woodhouse
2004-06-06 15:58 ` Mike McCormack
2004-06-07 8:49 ` David Howells
[not found] <23Y4Y-6F5-1@gated-at.bofh.it>
[not found] ` <240qb-8ir-7@gated-at.bofh.it>
[not found] ` <240Tc-gV-5@gated-at.bofh.it>
[not found] ` <2412S-pU-3@gated-at.bofh.it>
[not found] ` <24vX0-81P-7@gated-at.bofh.it>
2004-06-07 17:40 ` Andi Kleen
2004-06-08 9:42 ` Eric W. Biederman
[not found] ` <24WNz-4pO-3@gated-at.bofh.it>
2004-06-10 18:57 ` Bill Davidsen
2004-06-10 21:33 ` Robert White
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040608092055.GX4736@devserv.devel.redhat.com \
--to=jakub@redhat.com \
--cc=arjanv@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mike@codeweavers.com \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox