[v3] Mips support for PT_GNU_STACK

  From: "Dragan Mladjenovic" <dmladjenovic@wavecomp.com>

Hello everyone,

This is a third attempt to enable glibc to safely handle PT_GNU_STACK on Linux/Mips.
You can check out the previous discussion about this issue at [1] and [2].

A brief summary of the issue this is trying to address:

Up until the Linux kernel version 4.8 [3] MIPS FPU emulator used a small trampoline,
created on user stack, to handle delay slots when emulating FPU branches.
Because of this non-executable stack could not be enabled by default on MIPS.
The compatibility issue is that these old kernels respect PT_GNU_STACK,
making the stack non-executable if requested, and could crash the user process if
there would be need to emulate an instruction in the delay slot of an FPU branch.

In order to allow for the tool-chain to safely use PT_GNU_STACK by default, this patch
bumps the minimum kernel version to 4.8 for the hard-float builds done with GNU.stack
enabled tool-chain.

It would be nice if this could be back-ported as far back as glibc's policy allows.

Will be posting gcc side of the patch soon.

Best regards,

Dragan

[1] https://sourceware.org/ml/libc-alpha/2019-06/msg00889.html
[2] https://sourceware.org/ml/libc-alpha/2019-07/msg00280.html
[3] https://github.com/torvalds/linux/commit/432c6bacbd0c16ec210c43da411ccc3855c4c010

2019-08-04  Dragan Mladjenovic  <dmladjenovic@wavecomp.com>

	* sysdeps/unix/sysv/linux/mips/Makefile (test-xfail-check-execstack):
	Move under mips-has-gnustack != yes.
	* sysdeps/unix/sysv/linux/mips/configure.ac (mips-has-gnustack): New var.
	Use value of libc_cv_as_noexecstack.
	Set arch_minimum_kernel=4.8.0 for hard-float, noexecstack builds.
	* sysdeps/unix/sysv/linux/mips/configure: Regenerated.
---
 sysdeps/unix/sysv/linux/mips/Makefile     | 9 ++++-----
 sysdeps/unix/sysv/linux/mips/configure.ac | 5 +++++
 2 files changed, 9 insertions(+), 5 deletions(-)
  

On Sun, 4 Aug 2019, Dragan Mladjenovic wrote:

> In order to allow for the tool-chain to safely use PT_GNU_STACK by 
> default, this patch bumps the minimum kernel version to 4.8 for the 
> hard-float builds done with GNU.stack enabled tool-chain.

I think this explanation needs expanding.  What is meant by "GNU.stack 
enabled tool-chain"?  How do you control whether a toolchain you build is 
such a toolchain or not?

If simply building new-enough GCC and glibc quietly results in a new 
kernel requirement without any special configure options being needed, 
that could be a problem - we'd need to consider carefully whether such an 
increase is desirable, or whether it's only appropriate given a suitable 
--enable-kernel option.

Certainly the new feature needs a NEWS entry in any case.

> It would be nice if this could be back-ported as far back as glibc's 
> policy allows.

I don't think this sort of new feature is suitable for backporting at all, 
and an increase to the minimum kernel version certainly isn't.
  

On 05.08.2019. 21:25, Joseph Myers wrote:
> On Sun, 4 Aug 2019, Dragan Mladjenovic wrote:
> If simply building new-enough GCC and glibc quietly results in a new
> kernel requirement without any special configure options being needed,
> that could be a problem - we'd need to consider carefully whether such an
> increase is desirable, or whether it's only appropriate given a suitable
> --enable-kernel option.
>

Well, inverted logic would also work for me. That we force executable 
stack (-Wa,-execsatck) for a hard-float builds that don't specify 
--enable-kernel or otherwise have an minimum kernel version of 4.8.

It doesn't change the status quo that much. Glibc would still have 
executable stack, but now it would be explicit. If user increases 
minimum kernel version up to 4.8 then he can have the usual behavior of 
executable stack depending on gcc defaults.

That way we could have the gcc configured against glibc 2.31 + glibc 
2.31 that has minimum kernel version of 4.8 with non-executable stack by 
default.

Best regards,

Dragan