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)
> -----Original Message-----
> From: libc-alpha-owner@sourceware.org [mailto:libc-alpha-
> owner@sourceware.org] On Behalf Of Joseph Myers
> Sent: Saturday, September 23, 2017 2:05 AM
> To: John David Anglin <dave.anglin@bell.net>
> Cc: Jeff Law <law@redhat.com>; Carlos O'Donell <carlos@redhat.com>; GNU C
> Library <libc-alpha@sourceware.org>; Mike Frysinger <vapier@gentoo.org>;
> Helge Deller <deller@gmx.de>
> Subject: Re: Fix hppa/ia64/microblaze executable stack default (bug 22156)
>
> On Fri, 22 Sep 2017, John David Anglin wrote:
>
> > On 2017-09-22, at 4:11 PM, Joseph Myers wrote:
> >
> > > Given what Andreas said at
> > > <https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01220.html>, does
> > > this mean there are other causes of executable stacks in the kernel,
> > > such as VM_STACK_DEFAULT_FLAGS? If so, maybe hppa and microblaze
> do
> > > in fact need the GCC patch rather than the glibc one?
> >
> > VM_STACK_DEFAULT_FLAGS defaults to VM_DATA_DEFAULT_FLAGS when it
> is
> > not defined, and it is not defined on hppa.
> >
> > On hppa, VM_DATA_DEFAULT_FLAGS, and it is:
> >
> > #define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | VM_EXEC |
> \
> > VM_MAYREAD | VM_MAYWRITE |
> > VM_MAYEXEC)
>
> Given this, and your experiment showing the stack is indeed executable on
> hppa, are the hppa parts of the GCC patch OK? (I think we've established that
> ia64 should use the glibc change. Based on VM_DATA_DEFAULT_FLAGS,
> microblaze would use the GCC change but hopefully there will be more
> information from microblaze people soon.)
Yes, for Microblaze we need to apply GCC patch.
I have applied the patch and found no regressions with it.
Thanks,
Nagaraju
> --
> Joseph S. Myers
> joseph@codesourcery.com