What ever happens, somebody needs to test kernels with this patch
against old distros (Debian for example) to make sure you don't break them.
Some of the initial non-exec-stack patch sets intentionally broke
compatibility with existing binaries, and that is not acceptable.
David Daney
On 06/30/2016 10:40 AM, Faraz Shahbazker wrote:
Hi Paul,
The user-mode patch hasn't gone upstream either, so it is open to modification. Assuming the kernel currently has no other means of publishing RIXI support, or there is no existing software relying on such publication, then a RIXI bit in HWCAP seems appropriate.
@Matthew/@Maciej: If this is a priority, could we swap the libc-abi numbers for IFUNC(4) and non-exec stack(5) to push this change through before IFUNC? I think that is the only reason we've held the user-mode patches for glibc and gcc. A binutils patch with abiversion=5 was committed, so it will need fixing, but its only a one-liner.
Regards,
Faraz
On 06/30/2016 09:25 AM, Paul Burton wrote:
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
