This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 0/3] Mips support for PT_GNU_STACK
- From: Faraz Shahbazker <fshahbazker at wavecomp dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Dragan Mladjenovic <dmladjenovic at wavecomp dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, Joseph Myers <joseph at codesourcery dot com>, Carlos O'Donell <carlos at redhat dot com>, "Maciej W. Rozycki" <macro at linux-mips dot org>
- Date: Fri, 28 Jun 2019 16:19:03 +0000
- Subject: Re: [PATCH 0/3] Mips support for PT_GNU_STACK
- References: <1561672142-5907-1-git-send-email-dmladjenovic@wavecomp.com> <87lfxmp0q1.fsf@oldenburg2.str.redhat.com>
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.
We'd lose the ability to build against older kernel headers and work seamlessly
with newer kernels. This is not ideal, but it is more important to get a
working non-executable stack solution out in user space.
> 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
Regards,
Faraz