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>, Paul Burton <pburton at wavecomp dot com>
- Date: Fri, 28 Jun 2019 12:21:23 +0000
- Subject: Re: [PATCH 0/3] Mips support for PT_GNU_STACK
- Arc-authentication-results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0Q/8I0OAOtKUxCFS6XwV7BbVBOCsLZB4voD6MDFxx3c=; b=RxORQiEM5ons2JLXJQ93Wfm/PPFhMvlYLBAUWqgj2oAPT/lURpBD+X4MgQcrwoXNPLioyQV330vaqe9L8GYf0WDRzsW1Bh0tA7uxvLbUtUBwmtTdJ17QDuyCbhzS1OD37Dn4RL1fgSV8VgPQOiV2b0qdQ5mMhY/uJUui3iGjBsg=
- Arc-seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=hJR8qxGqJs8+yh3nGAJw9HGSvhHcIyJgjfn0/aZvS3LWJrki7V19x5Z95fPOVLET3dAi4xdEOnGnRCmwpm24DbTyjF7pm0KhTEq4eDcxWBW8DsAGonepYj95CGbKKYSy8XfVvyEscda1BgsN8bwtnITLRdq/Kd2D18mE8paSBjA=
- References: <1561672142-5907-1-git-send-email-dmladjenovic@wavecomp.com>,<87lfxmp0q1.fsf@oldenburg2.str.redhat.com>
Thanks for the comment.
>> 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.
I'm not particularly fond of doing version checks, but this something
that is already done to enforce minimum kernel version supported
by the glibc. Not sure this would be more broken that that.
> 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.
I don't think that any new change on kernel side will make this change
obsolete or broken. At best if some kind of the signal gets provided by
the kernel in the future that would allow us the have a real non-executable stack
on pre-4.8 kernel + 4.8 patch + future patch that provides the signal.
Best regards,
Dragan