Re: [PATCH] Set __libc_stack_end earlier on all arches,...

[Jakub Jelinek <jakub@redhat.com>]

On Wed, Sep 24, 2003 at 01:41:01PM -0500, Steven Munroe wrote:
> Jakub Jelinek Wed, 24 Sep 2003 15:47:04 writes:
> 
> > The following patch does that (tested on a bunch of arches).
> 
> Actually it does not include PowerPC 32/64. Currently for PowerPC linux
> __libc_stack_end is set in libc_start_main, but this is not soon enough to
> support execstack and the execstack tests in make check fails (because
> __libc_stack_end is not set). The attached patch uses DL_PLATFORM_INIT to
> capture the argv pointer and store that into __libc_stack_end during
> _dl_sysdep_start before the call to dl_main. This will work for both powerpc32
> and powerpc64.
> 
> This is soon enough to pass the stack-end into _dl_make_stack_executable but it
> still fails in the mprotect with a "Permission Denied". I'll pursue that issue
> further.
> 
> I would like an explanation of why we are doing this. Generally arbitrarily
> marking the stack executable is a bad idea. So I would like a explaination
> (pointer to one) of the function we trying to provide and the conditions under
> which it will be used.

Normally on ppc32 all processes get executable stack, which is not exactly
secure. But you cannot disable it blindly for all processes, as you don't
know if they really need it or not.
ppc32 needs executable stack for trampolines (e.g. when you take address
of a nested function in C). Recent GCC+binutils mark objects with
.note.GNU-stack segment (either "" or "x" depending on whether it needs
executable stack or not) and ld merges this into PT_GNU_STACK segment.
If a binary has PT_GNU_STACK PF_R|PF_W|PF_X (or no PT_GNU_STACK segment),
kernel needs to assume the program needs (or might need) executable stack.
If a binary has PT_GNU_STACK PF_R|PF_W, kernel can assume the program
doesn't need executable stack and can change its VMA permissions.
This all can be done in gcc/binutils and kernel, no glibc help needed.
But now, if you have PT_GNU_STACK PF_R|PF_W binary which dlopens
some library which needs or might need executable stack (or depends on
such library through DT_NEEDED), kernel which only sees that binary
and the dynamic linker and might tighten stack permissions while
they actually need to be executable for the library. Here is when ld.so
needs to change the permissions.
In similar situation to ppc32 are most other linux arches (i386, amd64,
...).
The only special arches here are ia64 and ppc64, as there trampolines
don't actually need executable stack. Because of this I chose not to
add .note.GNU-stack/PT_GNU_STACK marking for these two arches.
Unfortunately, on both these arches kernel defaults to executable stack
as I found out today and thus there can be programs which rely on this
and so for binary compatibility need to be assumed as needing executable
stack too. Which means I'll probably have to mark all ia64/ppc64
gcc output with .section .note.GNU-stack, "" and let all binaries be
marked too (which one can always override using -Wa,--execstack or
-Wl,-z,execstack).

> 2003-09-24  Steven Munroe  <sjmunroe@us.ibm.com>
> 
> 	* sysdeps/unix/sysv/linux/powerpc/dl-sysdep.c 
> 	[DL_PLATFORM_INIT]: Define
> 	(frob_stack_end): New function.

Why do you need this? Isn't the __libc_stack_end patch I've posted
sufficient for ppc32/ppc64? Certainly I haven't seen any tst-execstack*
failures on either ppc32 or ppc64.

ppc32:
sysdeps/powerpc/powerpc32/dl-start.S sets
mr      r3,r1
which becomes argument to _dl_start, which passes arg
directly do _dl_start_final and that one to
_dl_sysdep_start.
sysdeps/unix/sysv/linux/powerpc/dl-sysdep.c includes
sysdeps/generic/dl-sysdep.c for _dl_sysdep_start
and there my patch sets __libc_stack_end to that argument.

ppc64:
similarly, just the first step is in
sysdeps/powerpc/powerpc64/dl-machine.h (RTLD_START):
mr      3,1

	Jakub