ia32 binfmt problem with x86-64

ia32 binfmt problem with x86-64

[Markus Schoder]

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).

--
Markus

Re: ia32 binfmt problem with x86-64

[Arjan van de Ven]

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.

So... fix the app ! (and.. which app is this ?)

Greetings,
    Arjan van de Ven

Re: ia32 binfmt problem with x86-64

[lists]

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

Re: ia32 binfmt problem with x86-64

[Andi Kleen]

lists@gammarayburst.de writes:
> 
> This all makes sense. But 64 bit and 32 bit apps should get the same
> treatment right?

No - i386 behaves different here than x86-64.

x86-64 always had NX/PROT_EXEC (although not all CPUs have always enforced it)
while i386 has lots of legacy binaries that don't know about it.

-Andi

Re: ia32 binfmt problem with x86-64

[Markus Schoder]

On Tuesday 27 June 2006 10:43, Andi Kleen wrote:
> lists@gammarayburst.de writes:
> > 
> > This all makes sense. But 64 bit and 32 bit apps should get the same
> > treatment right?
> 
> No - i386 behaves different here than x86-64.
> 
> x86-64 always had NX/PROT_EXEC (although not all CPUs have always enforced it)
> while i386 has lots of legacy binaries that don't know about it.

But then 32 bit apps should be handled in a less restrictive fashion
than 64 bit apps, no? And also probably only for binaries that do
not have the exec_stack flag at all.

What I fail to understand then is why a 64 bit application with the
exec_stack flag set gets read_implies_exec and a 32 bit application
also with the exec_stack flag set does not (this is also the only case
where the behavior differs).

--
Markus