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

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 17/07/2019 18:47, Dragan Mladjenovic wrote:
> 
> 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.

It seems the kernel commit that actually added this support on mips was 
432c6bacbd0c16ec210c43da411ccc3855c4c010.  Isn't there any other mechanism to check 
for kernel support without tying a kernel version check? 

The code seems to reserve an extra page for the delay slot emulation, could we
infer based on vdso placement, page size, and maximum stack size? 

Otherwise I think we should do as usual, which is just assumes non-executable stack if
glibc is configure for kernel higher than 4.8 (with --enable-kernel). Checking on
patch submission history, Florian also stated that runtime version check is not
an option here.

> 
>>>  
>>> 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. 

I don't have a strong opinion here, although the main issue here is runtime support
provided by underlying kernel rather than an ABI issue in fact.  

One option is just to check if compilers sets GNU.stack as default to require a
minimum kernel version of 3.8 (as we already did for 2008 NaN on d5f2798a0ac9).

> 
>>> 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.

If a distribution aims to backport this features, it will need to coordinate on 
multiple parts (kernel, compiler, runtime), so I prefer to avoid trying to 
provision this beforehand.  I would go to with a simpler solution, instead of
adding runtime/configure checks.

> 
> 
> Best regards,
> 
> Dragan
>