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
