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>, Carlos O'Donell <carlos at redhat dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, Joseph Myers <joseph at codesourcery dot com>, "Maciej W. Rozycki" <macro at linux-mips dot org>, Faraz Shahbazker <fshahbazker at wavecomp dot com>
- Date: Fri, 5 Jul 2019 12:52:19 +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>
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.
>
> 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.
I'm interested if proposed compromise is acceptable for the community to be done in this release cycle?
If not what else can we do to move this issue forward?
Best regards,
Dragan