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: Dragan Mladjenovic <dmladjenovic at wavecomp dot com>
- To: Florian Weimer <fweimer at redhat 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>, Faraz Shahbazker <fshahbazker at wavecomp dot com>, Rich Felker <dalias at libc dot org>
- Date: Tue, 9 Jul 2019 22:39:57 +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> <DM5PR22MB06836199BF24B646E7BF5B85D0FC0@DM5PR22MB0683.namprd22.prod.outlook.com>,<87lfx8u44g.fsf@oldenburg2.str.redhat.com>
On 08.07.2019. 14:01, Florian Weimer wrote:
>> 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-/
The user can lie via LD_ASSUME_KERNEL env or by hacking the kernel,
but that implies that they know what they are doing.
There is an use-case of someone wanting to back-port the 4.8 kernel patch to their older
kernel and have glibc chose to honor the RW GNU_STACK.
Version check doesn't help here, and while it sounds a bit far-fetched I guess one could
be tempted to hack the kernel version along the way.
Having something else than version check would be better in above case, but until that hits
the mainline we could as well move to 4.8 as minimum kernel version.
>>> 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).
If someone in the future would decide do go back to the
old kernel behavior of "randomly"* crashing user-space application that use
RW GNU_STACK we would be in the problem ether way.
* Not really random, but might as well be.
Best regards,
Dragan