On Fri, 8 Jul 2016, Faraz Shahbazker wrote:
> On 07/08/2016 09:36 AM, Maciej W. Rozycki wrote:
> > implementation previously present, and the MIPS port specifically has been
> > updated to actually report this at the EI_ABIVERSION offset of the
> > `e_ident' array of the ELF header with commit 17733f5be961 ("Increment the
> > ABIVERSION to 5 for MIPS objects with non-executable stacks."), earlier
> > this year (it's not clear to me offhand why we need to do this rather than
> > relying on the lone presence of PT_GNU_STACK, but I'm sure someone will
> > enlighten me).
>
> This was simply to be able to check whether the tools support a safe non-exec
> stack scheme, before enabling it as a default in the compiler. Refer to the
> attached e-mail from Matthew. Neither linker nor compiler patch is upstream.
Hmm, now I am really confused: what problem are we trying to solve on the
toolchain side?
As I understand the current state of affairs, we have now have a
situation where the toolchain may be asked (although it is not on by
default) to produce a MIPS PT_GNU_STACK binary, which will be happily
executed by the kernel with the execution permission disabled for the
stack memory (where supported by hardware, i.e. RIXI), however then it
will itself happily try to execute from that stack memory in the FPU
emulator.
So first of all we need to address the problem in the kernel by making
the FPU emulator avoid stack execution. That will fix PT_GNU_STACK
support on our target.
Second we want to enforce the non-executable-stack policy in the userland
by adding a check early on in glibc startup for a flag, such as in the
FLAGS entry of the auxiliary vector, set by a fixed kernel only, telling
glibc that the presence of PT_GNU_STACK has been respected by the kernel,
and make the startup bail out right away if the flag is not there.
So where does the static linker EI_ABIVERSION update fit here? What is
it needed for? What have I missed?
Maciej
