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

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

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.