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

[Faraz Shahbazker <fshahbazker@wavecomp.com>]

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?

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

Regards,
Faraz