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

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

On 18/07/2019 16:49, Dragan Mladjenovic wrote:
> 
> 
> On 18.07.2019. 15:38, Adhemerval Zanella wrote:
>>
>>
>> On 17/07/2019 19:59, Faraz Shahbazker wrote:
>>> On 07/17/2019 12:43 PM, Adhemerval Zanella wrote:
>>>> 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.
>>>
>>> The original proposal was to advertise through AT_FLAGS. I've heard this suggestion of using
>>> hwcap from multiple sources, so I am curious - what other *purely* software kernel features
>>> are advertised using hwcap?
>>
>> It is not common, but on powerpc has both PPC_FEATURE2_HTM_NOSC and
>> PPC_FEATURE2_HTM_NO_SUSPEND which is kernel behaviour regarding transaction
>> memory state and syscall execution.
>>
>>>
>>>>> 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.
>>>
>>> It is not really hardening, the way glibc handles PT_GNU_STACK is along the lines of
>>> 'may have non-executable stack' rather than 'must have non-executable stack'. However
>>> the MIPS backend overrides *any* incoming PT_GNU_STACK permissions using the default (RWX)
>>> permissions for MIPS, in effect enforcing 'will not have non-executable stack'. What is
>>> being indicated here is a change in this default behaviour. The ABI version bump would
>>> indicate whether PT_GNU_STACK permissions will be honoured (at least to the extent it is
>>> by other architectures) or simply ignored (as it has historically been).
>>>
>>> IMO, the current behaviour of PT_GNU_STACK for MIPS is an anomaly in itself. What should
>>> have been, is a rejection of non-executable PT_GNU_STACK at some level, instead of silently
>>> overriding it in glibc. So are you of the opinion that this change in glibc behaviour is not
>>> worth being published at all, or that it should be advertised using a different mechanism
>>> instead of an ABI version bump?
>>
>> Since non-executable stack is tied with underlying kernel support rather than
>> ABI, my suggestion is just to assume non-executable stack as default, without
>> permission override, if glibc is configure for kernel higher than 3.8. We will
>> need to live with old behaviour for default builds.
>>
> 
> If I follow correctly this can be simplified to either require 4.8 
> kernel when built with non-executable stack or force executable stack at 
> build time for default (< 4.8) builds?
> 
> Just to be on the same page. This "old" behavior of overriding 
> PT_GNU_STACK permission to RWX on mips is introduced in the second patch 
> of the series.
> 
> What I understand is that previously you could build a glibc with RW 
> PT_GNU_STACK and it may or may not work at runtime depending on if the 
> kernel actually needed to use you stack for emulation and if you 
> hardware is capable of enforcing NX page protection.
> 
> If linker, glibc or kernel did historically disallow RW PT_GNU_STACK we 
> would not have this issue.
> 
> I interpret this abi version bump more as assurance that we are not 
> running in the environment that might crash just because we requested
> RW PT_GNU_STACK. (I'm ignoring existence of other libc implementations 
> here.)

My understanding is ELFOSABI_SYSV check is only required if we build glibc
with support for kernel older than 3.8, to make newer binaries fail early 
on kernels that might not honour the PT_GNU_STACK.

So indeed it might a good idea to bump ELFOSABI_SYSV for to handle this case.