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

[Florian Weimer <fweimer at redhat dot com>]

* Faraz Shahbazker:

> On 6/28/19 1:34 AM, Florian Weimer wrote:
>>> 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.
>> 
>> People patch their kernels to lie about the version, so I don't think
>> this is correct.
>
> Could a possible compromise be to forego the run-time check and
> instead make the non-exec stack override trigger statically for MIPs
> when building glibc with 4.8 or later kernel headers? In that case,
> the potential gap between glibc's expectation and an old kernel
> masquerading as a newer version is exactly what it would be for the
> usual minimum kernel version check.

The minimum kernel version check is the reason why kernels are patched
to lie about their version. 8-/

>> Kernel developers also think it's acceptable to change compatibility
>> mechanisms that have already been deployed in binutils or glibc, so I
>> really think this needs to wait until some signal has been added to the
>> the auxiliary vector in a mainline kernel.
>
> Note that as it stands, this is not an interface between the kernel
> and glibc.  Non-executable stack support is looked upon as a security
> fix in the kernel and hence is not liable to flip back and forth, to
> the extent that there isn't a KConfig setting which allows one to
> build the kernel without it. The auxiliary vector OTOH would be a
> compatibility mechanism between the kernel and glibc and hence would
> be vulnerable to the malicious manipulations of those devious kernel
> developers :D

Not sure I understand.  We have the same problem with vsyscall.  Its
absence is also advertised as a security feature, and yet there is no
easy way to detect that the kernel is missing what was once a key piece
of the x86-64 userspace ABI.

Based on the vsyscall experience, lack of a reliable detection mechanism
means that it can be impossible to get old userspace ready for new
kernels (because you can't just conventionalize code and limit the
impact on legacy products which share the same binaries).

Thanks,
Florian