From: lists@gammarayburst.de
To: arjan@infradead.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: ia32 binfmt problem with x86-64
Date: Mon, 26 Jun 2006 13:22:10 +0200 (CEST) [thread overview]
Message-ID: <20060626112210.307DB1A04006@prtg1.pretago.de> (raw)
Arjan van de Ven wrote:
> On Mon, 2006-06-26 at 01:43 +0200, Markus Schoder wrote:
> > The 32 bit emulation for x86-64 has the following in
> > arch/x86_64/ia32/ia32_binfmt.c:
> >
> > #define elf_read_implies_exec(ex, have_pt_gnu_stack) \
> > (!(have_pt_gnu_stack))
> >
> > I guess it should be same definition as in include/asm-i386/elf.h
and
> > include/asm-x86_64/elf.h instead:
> >
> > #define elf_read_implies_exec(ex, executable_stack) \
> > (executable_stack != EXSTACK_DISABLE_X)
> >
> > >From the usage in fs/binfmt_elf.c it looks like the semantics of
that
> > macro changed slightly but was not fixed in all places (ia64 seems
to
> > have a similar problem from the looks of it).
> >
> > The current behavior leads to 32 bit executables not setting the
> > READ_IMPLIES_EXEC personality when they are marked as requiring an
> > executable stack (64 bit executables do however).
>
> Hi,
>
> regardless of the inconsistency you found; I think the behavior is
> correct. "Legacy" binaries get read-implies-exec (since that is the
old
> behavior), "new" binaries get "we honor the stack you set". Why should
> read-implies-exec be set when an application asks for an executable
> stack? I disagree that it should be set; the application should just
use
> the proper PROT_EXEC flags for its allocations; now it's not an option
> to fix legacy apps (the ones without the pt_gnu_stack marker), but for
> new things for sure is/was; this has been the case for the last... 3+
> years already.
This all makes sense. But 64 bit and 32 bit apps should get the same
treatment right? Currently 64 bit apps get read_implies_exec with
exec_stack but 32 bit apps do not. Obviously the 64 bit behaviour is the
intended one this is clear from the comments in the code for
elf_read_implies_exec.
I don't feel very strongly about which way it is fixed. Biggest problem
is probably that developers on non NX boxes do not even see a problem if
they get the exec flag wrong.
> So... fix the app ! (and.. which app is this ?)
It is the demo of the newly released game by linuxgamepublishing Gorky
17. Don't know wether it is in the full version as well but it seems
likely.
Anyway I care more about the kernel getting fixed.
I guess I can put a personality wrapper in place to force
read_implies_exec for individual apps anyway.
--
Markus
next reply other threads:[~2006-06-26 11:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-26 11:22 lists [this message]
2006-06-27 8:43 ` Andi Kleen
2006-06-27 19:03 ` Markus Schoder
-- strict thread matches above, loose matches on Subject: below --
2006-06-25 23:43 Markus Schoder
2006-06-26 8:30 ` Arjan van de Ven
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=20060626112210.307DB1A04006@prtg1.pretago.de \
--to=lists@gammarayburst.de \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®