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

[Dragan Mladjenovic <dmladjenovic at wavecomp dot com>]

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

Best regards,

Dragan