On 30/06/16 13:04, Matthew Fortune wrote:
There will be some extra work on top of this to inform user-mode that
no-exec-stack support is actually safe. I'm a bit fuzzy on the exact
details though as I have not been directly involved for a while.
https://www.sourceware.org/ml/libc-alpha/2016-01/msg00719.html
Adding Faraz who worked on the user-mode side and Maciej who has been
reviewing.
Hi Matthew,
Interesting. That glibc patch seems to imply that the kernel already
supports this, which isn't true. It makes use of a
"AV_FLAGS_MIPS_GNU_STACK" constant & says that's taken from Linux, but
it doesn't exist. Are you using an experimental patch for the kernel
side (perhaps Leonid's?). I'm not sure why you'd use AT_FLAGS for this,
which Linux currently unconditionally sets to 0 for all architectures.
Would a HWCAP bit for RIXI perhaps be more suitable?
We are/were under the assumption that a pre-existing kernel will honor
the PT_GNU_STACK marker overriding the arch specific read-implies-exec
logic:
http://lxr.free-electrons.com/source/fs/binfmt_elf.c?v=3.2#L689
http://lxr.free-electrons.com/source/fs/exec.c?v=3.2#L703
This means that if we produce tools which have PT_GNU_STACK with executable
stack disabled then older kernels will crash as they will obey it and
the FPU emulator will break.
Is this incorrect? I.e. does today's MIPS kernel do absolutely nothing
when PT_GNU_STACK is seen?
Hi Matthew,
No I believe what you've described there is correct, existing kernels on
systems with RIXI will make the stack non-executable for binaries with a
non-executable PT_GNU_STACK, and that will cause problems for the
kernels delay slot emulation code (used by the FPU emulator & pre-MIPSr6
emulation on MIPSr6 systems).
The "AV_FLAGS_MIPS_GNU_STACK" is a proposal of how to handle the
transition from a kernel that does as I describe above to one that safely
supports no-exec-stack. I don't know if this has to be an AT_FLAGS or
whether a HWCAP would do. I think we perhaps latched on to the idea of
AT_FLAGS as we have used that as part of the nan2008 work but we can
work through that detail later. The user-mode work is still very much in
review. There is no kernel with this feature yet.
This part is probably something we need to discuss - though I suppose it
could if needed go in after these kernel changes, just not before them.
Having gone digging I see Maciej used AT_FLAGS in some NaN support that
hasn't yet been submitted for merging. There was this RFC:
https://patchwork.linux-mips.org/patch/11490/
https://patchwork.linux-mips.org/patch/11491/
https://patchwork.linux-mips.org/patch/11492/
https://patchwork.linux-mips.org/patch/11493/
...but no non-RFC submission so the code isn't yet in the kernel. Right
now AT_FLAGS is unconditionally 0 in Linux, for all architectures:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/binfmt_elf.c?id=v4.7-rc5#n241
Presuming it's still the plan to get this NaN code into mainline the use
of AT_FLAGS seems less odd to me. I still think a HWCAP bit would be a
sane alternative though as this patchset can be seen as completing
kernel support for RIXI, so indicating that a system properly supports
RIXI makes sense (& implies that the stack may be non-executable).
Faraz: Did I explain that correctly?
I'd love to get your input on this too Faraz.
Thanks,
Paul
