This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fix hppa/ia64/microblaze executable stack default (bug 22156)
- From: Jeff Law <law at redhat dot com>
- To: Carlos O'Donell <carlos at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, libc-alpha at sourceware dot org, dave dot anglin at bell dot net
- Cc: vapier at gentoo dot org
- Date: Tue, 19 Sep 2017 08:42:35 -0600
- Subject: Re: Fix hppa/ia64/microblaze executable stack default (bug 22156)
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 705CF7E445
- References: <alpine.DEB.2.20.1709191345040.2962@digraph.polyomino.org.uk> <4b7b99f2-9f64-92a4-8344-3589fc6b00c1@redhat.com>
On 09/19/2017 07:56 AM, Carlos O'Donell wrote:
> On 09/19/2017 07:46 AM, Joseph Myers wrote:
>> As per https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01220.html hppa,
>> ia64 and microblaze default to non-executable stacks in the Linux
>> kernel. glibc however defines DEFAULT_STACK_PERMS to include PF_X for
>> those architectures, meaning (a) elf/check-execstack fails and (b)
>> (from code inspection, not tested, but this is why I think this is a
>> user-visible bug) thread stacks are unnecessarily mapped with execute
>> permission. This patch fixes the DEFAULT_STACK_PERMS definitions in
>> question.
>>
>> Tested (compilation only) with build-many-glibcs.py for those
>> configurations. This fixes the check-execstack failure (hppa still
>> has a check-textrel failure as the only remaining issue stopping that
>> architecture having clean build-many-glibcs.py results; hopefully
>> architecture maintainers can help resolve that).
>
> I thought that PF_X was required for hppa because there was still code
> generated by gcc for hppa that needed it? Otherwise *I* would have
> removed it when I did the PT_GNU_STACK cleanups for all the arches.
>
> Dave is the best positioned to answer this question.
I don't think the PA was ever converted to the new bits from the Adacore
guys -- meaning I think it still generates executable stack trampolines
for nested functions.
Dave would know for sure :-)
jeff