Re: [PATCH v2 0/3] Mips support for PT_GNU_STACK

[Dragan Mladjenovic <dmladjenovic at wavecomp dot com>]

On 17.07.2019. 21:43, Adhemerval Zanella wrote:
>
> On 15/07/2019 15:23, Dragan Mladjenovic wrote:
>> Hello everyone,
>>
>> Patches in this series are a slight variation of work done previously by
>> Faraz Shahbazker [1] in 2016.
>>
>> A brief summary of the issue this is trying to address:
>>
>> Up until the Linux kernel version 4.8 [2] 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 and to
>> provide the compatibility with pre-4.8 kernels, the original patch would revert
>> stack protection back to executable stack if it could not detect that kernel
>> supports non-executable stack.
>>
>> The form of detection the patch proposes is not yet provided by the kernel.
>> Instead, this version of the patch does kernel version check at runtime and
>> provides compatible behavior if it cannot detect the 4.8 kernel or newer.
> I think checking the kernel version is the wrong approach, it prevents a distribution
> to backport the kernel fix without also applying a out-of-tree patch to fix it on glibc
> as well.  IMHO the proper way would be to make kernel advertise it through hwcap, as
> other architectures do for similar kernel features and not tie it to any specific
> version.

First, thanks for the comments.
 
I agree with everything and the original patch did propose the usage of AT_FLAGS
auxval for this purpose. But, sadly, the kernel still doesn't advertise this information
to the user mode and it would take some time for it to be back-ported even if it gets
implemented, let's say in next kernel release. Meanwhile, this approach, while lacking,
would allow for distributions to enable PT_GNU_STACK way earlier and to actually
enjoy the benefit of it on existing 4.8+ kernels while remaining compatible with pre-4.8
ones.

>>  
>> The last patch increments the ABI Version number in order to disallow new
>> binaries to run with older glibc. The number is not set in stone.
>> I'm assuming it will probably land after GNU_HASH [3] support which consumes
>> ABI version 5 for MIPS. I will send a proposal for Binutils and GCC after this
>> part gets finalized.
> If the idea is to fallback to executable stack for the case of underlying missing
> kernel support, which is the net gain in adding this requirement? My understanding
> it ABI bump should be used to fail early for the cases where the new binaries
> requires loader support that can not be provided (iFUNC or new relocations), not
> for hardening.

True, and that is the reason I'm not hard pressed for this part of the patch. Though one
nice benefit form it is that it prevents you from accidentally using the GNU.stack enabled
mips toolchain to build glibc w/o this patch. I guess that can be prevented on gcc side if
glibc is built as part of the toolchain build, but otherwise, this would require some discipline
form the end user.

Without this, the dynamically liked binaries/shared objects would still work with older glibcs.
Given that existing distributions are build w/o PT_GNU_STACK they would get the executable
stack anyway. Statically linked binaries would be handled by linked libc. So we are safe on
pre-4.8 kernels.

This should work as long as there is no RW PT_GNU_STACK built glibc w/o this patch in "the wild".

>From my point of view this is more to enable, at least for glibc based environment,
RW PT_GNU_STACK by default w/o having the end-user worrying on which kernel will it run
than it is to enforce the hardening. 

>> Even if this part doesn't get in the next release due to issues [4] with ABI
>> version handling, it would be still nice if the back-compat support gets in.
>> I would like to hear your thoughts on this.
> If you don't tie it support to kernel version checks or require bump the ABI version,
> it should be fair straight to backport it.

Another option that came up during the v1 discussion is to actually require 4.8 as minimal
kernel version if glibc gets build with RW PT_GNU_STACK.

If it gets back-ported far enough, that approach would satisfy the requirement that there is no
RW PT_GNU_STACK glibc running on the pre-4.8 kernels which would still allow us to enable 
GNU.stack on GCC by default, at least for mips*-*-gnu* triplets.


Best regards,

Dragan