Maciej Rozycki <Maciej.Rozycki@xxxxxxxxxx> writes:
> 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?
The problem was that if we just turn on no-exec-stack support in GCC then
when someone combines that with an older binutils and/or build glibc
from source (using those tools) then they would get an executable that
asked for a non-executable stack and the kernel would willingly do so.
However, this would then crash. So we need a way to prevent the generic
logic in glibc's build system from creating a no-exec-stack library until
we have the kernel checks in place in glibc to undo no-exec-stack. This
then leads to the convoluted system of increased EI_ABIVERSION (or some
other equally complex plan) to ensure mix-and-match of new and old tools
glibc and kernel all behave nicely.
> 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.
Yes.
> 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.
Yes.
> So where does the static linker EI_ABIVERSION update fit here? What is
> it needed for? What have I missed?
Making sure new GCC + new binutils + old glibc (from source) does not create
executables that crash. My proposal was to also make sure that a MIPS GCC
with no-exec-stack support would fail the generic glibc build system test
for no-exec-stack and instead need a new MIPS specific test so that old
glibc built from source never ended up with no-exec-stack support for MIPS.
I'd love to simplify all this if for some reason this isn't actually a
problem. I was trying to stick to the principle of all combinations of old
and new tools/libraries should just work.
Matthew
