RE: Enable no-exec stacks for more targets using the Linux kernel

[Nagaraju Mekala]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Nagaraju Mekala
> Sent: Thursday, September 21, 2017 2:56 PM
> To: Joseph Myers 
> Cc: sch...@suse.de; gcc-patches@gcc.gnu.org; l...@redhat.com;
> d...@anglin.bell.net; wil...@tuliptree.org; Michael Eager
> 
> Subject: RE: Enable no-exec stacks for more targets using the Linux kernel
> 
> [This sender failed our fraud detection checks and may not be who they
> appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
> 
> > -Original Message-
> > From: Joseph Myers [mailto:jos...@codesourcery.com]
> > Sent: Wednesday, September 20, 2017 5:52 PM
> > To: Nagaraju Mekala 
> > Cc: sch...@suse.de; gcc-patches@gcc.gnu.org; l...@redhat.com;
> > d...@anglin.bell.net; wil...@tuliptree.org; Michael Eager
> > 
> > Subject: Re: Enable no-exec stacks for more targets using the Linux
> > kernel
> >
> > On Wed, 20 Sep 2017, Nagaraju Mekala wrote:
> >
> > > > I've sent a glibc patch
> > > > .  I
> > > >think the key questions for architecture experts now are: on each
> > > >of those three architectures, do trampolines ever require
> > > >executable stacks, and, if they do, how does this work at present
> > > >when the kernel defaults to non-executable and my understanding at
> > > > would
> > > >be that glibc would only make thread stacks executable on those
> > > >architectures, not the main process stacks, and GCC will never
> > > >generate an explicit marker on those architectures to request an
> > > >executable
> > stack?
> > >
> > > Microblaze is a soft processor with many configuration options. If
> > > we don't use the MMU, there is nothing preventing execution of code
> > > on the stack in the MicroBlaze architecture.
> > >  With the MMU, you have the option to make any page, including the
> > > stack  pages, executable or not.
> > >
> > > It is recommended to prevent execution on the stack by defining
> > > those pages as non-executable in the MMU. In particular, trampolines
> > > would have to be possible to code without execution on the stack
> >
> > No-MMU configurations are not relevant to a glibc change; the question
> > is how things work for configurations using glibc, with the Linux
> > kernel, with an MMU.  In such a configuration, for MicroBlaze: (a) is
> > the stack in fact executable, now; (b) if it is, what makes it so
> > given the kernel default to non- executable (where does my reasoning
> > about what the kernel and glibc do go wrong); (c) if it is not executable, 
> > do
> trampolines work anyway?
> 
> The MMU configuration doesn't need stack to be executable.
> The glibc patch related to Microblaze looks correct and it should solve the
> issue.
> We will verify the change in a day or two and get back to you.
>
Sorry for the confusion. 
We need to apply this GCC patch for Microblaze target and make stack executable.
I have verified the patch and there are no regressions with it.
Thanks,
Nagaraju
> 
> > --
> > Joseph S. Myers
> > jos...@codesourcery.com

Re: Enable no-exec stacks for more targets using the Linux kernel

[Jakub Jelinek]

On Wed, Sep 20, 2017 at 12:25:46PM +, Joseph Myers wrote:
> On Wed, 20 Sep 2017, Andreas Schwab wrote:
> 
> > On Sep 19 2017, Joseph Myers  wrote:
> > 
> > > I've sent a glibc patch 
> > > .  I think 
> > > the 
> > > key questions for architecture experts now are: on each of those three 
> > > architectures, do trampolines ever require executable stacks, and, if 
> > > they 
> > > do, how does this work at present when the kernel defaults to 
> > > non-executable and my understanding at 
> > >  would be 
> > > that 
> > > glibc would only make thread stacks executable on those architectures, 
> > > not 
> > > the main process stacks, and GCC will never generate an explicit marker 
> > > on 
> > > those architectures to request an executable stack?
> > 
> > For ia64 on linux there is EF_IA_64_LINUX_EXECUTABLE_STACK to request
> > executable heap and stack.  But since ia64 uses function descriptors,
> > trampolines never need that.
> 
> Thanks.  I think this adequately confirms my glibc patch is safe for ia64.  
> The questions above remain for hppa and microblaze.

If for some architectures which generally don't need executable stack for
nested indirect function calls we don't want the .note.GNU-stack notes
in *.s files, the question is if the linker in that case shouldn't either
ignore those notes and either never generate PT_GNU_STACK segments,
or always generate it with RW, then either glibc/kernel can always rely on
missing PT_GNU_STACK - unclear, possibly executable stack, or PT_GNU_STACK
present, RW means no-exec, RWX means exec stack, or it can have some list of
architectures for which missing PT_GNU_STACK means non-exec stack.

The current state is really not very good, some *.s/*.S files have
.note.GNU-stack notes emitted regardless of architecture, e.g. for all linux
arches, while others (e.g. arch specific) don't have those notes.  And the
compiler sometimes emits them, sometimes it doesn't (e.g. RH ia64 gcc had
.note.GNU-stack emission patched in, while upstream didn't; similarly for
ppc64 (non-le)).  So when mixing that, there is often PT_GNU_STACK with RWX
e.g. on ia64 or ppc64 even when there is no exec stack.

Jakub

Re: Enable no-exec stacks for more targets using the Linux kernel

[Eric Botcazou]

> Thanks.  I think this adequately confirms my glibc patch is safe for ia64.
> The questions above remain for hppa and microblaze.

HP-PA uses function descriptors like IA-64 so same outcome.

-- 
Eric Botcazou

RE: Enable no-exec stacks for more targets using the Linux kernel

[Nagaraju Mekala]

> -Original Message-
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: Wednesday, September 20, 2017 5:52 PM
> To: Nagaraju Mekala 
> Cc: sch...@suse.de; gcc-patches@gcc.gnu.org; l...@redhat.com;
> d...@anglin.bell.net; wil...@tuliptree.org; Michael Eager
> 
> Subject: Re: Enable no-exec stacks for more targets using the Linux kernel
> 
> On Wed, 20 Sep 2017, Nagaraju Mekala wrote:
> 
> > > I've sent a glibc patch
> > > .  I
> > >think the key questions for architecture experts now are: on each of
> > >those three architectures, do trampolines ever require executable
> > >stacks, and, if they do, how does this work at present when the
> > >kernel defaults to non-executable and my understanding at
> > > would be
> > >that glibc would only make thread stacks executable on those
> > >architectures, not the main process stacks, and GCC will never
> > >generate an explicit marker on those architectures to request an executable
> stack?
> >
> > Microblaze is a soft processor with many configuration options. If we
> > don't use the MMU, there is nothing preventing execution of code on
> > the stack in the MicroBlaze architecture.
> >  With the MMU, you have the option to make any page, including the
> > stack  pages, executable or not.
> >
> > It is recommended to prevent execution on the stack by defining those
> > pages as non-executable in the MMU. In particular, trampolines would
> > have to be possible to code without execution on the stack
> 
> No-MMU configurations are not relevant to a glibc change; the question is
> how things work for configurations using glibc, with the Linux kernel, with an
> MMU.  In such a configuration, for MicroBlaze: (a) is the stack in fact
> executable, now; (b) if it is, what makes it so given the kernel default to 
> non-
> executable (where does my reasoning about what the kernel and glibc do go
> wrong); (c) if it is not executable, do trampolines work anyway?

The MMU configuration doesn't need stack to be executable.
The glibc patch related to Microblaze looks correct and it should solve the 
issue.
We will verify the change in a day or two and get back to you.

Thanks,
Nagaraju 

> --
> Joseph S. Myers
> jos...@codesourcery.com

Re: Enable no-exec stacks for more targets using the Linux kernel

[Joseph Myers]

On Wed, 20 Sep 2017, Andreas Schwab wrote:

> On Sep 19 2017, Joseph Myers  wrote:
> 
> > I've sent a glibc patch 
> > .  I think the 
> > key questions for architecture experts now are: on each of those three 
> > architectures, do trampolines ever require executable stacks, and, if they 
> > do, how does this work at present when the kernel defaults to 
> > non-executable and my understanding at 
> >  would be that 
> > glibc would only make thread stacks executable on those architectures, not 
> > the main process stacks, and GCC will never generate an explicit marker on 
> > those architectures to request an executable stack?
> 
> For ia64 on linux there is EF_IA_64_LINUX_EXECUTABLE_STACK to request
> executable heap and stack.  But since ia64 uses function descriptors,
> trampolines never need that.

Thanks.  I think this adequately confirms my glibc patch is safe for ia64.  
The questions above remain for hppa and microblaze.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Enable no-exec stacks for more targets using the Linux kernel

[Joseph Myers]

On Wed, 20 Sep 2017, Nagaraju Mekala wrote:

> > I've sent a glibc patch 
> > .  I think the 
> >key questions for architecture experts now are: on each of those three 
> >architectures, do trampolines ever require executable stacks, and, if they 
> >do, how does this work at present when the kernel defaults to 
> >non-executable and my understanding at 
> > would be that 
> >glibc would only make thread stacks executable on those architectures, not 
> >the main process stacks, and GCC will never generate an explicit marker on 
> >those architectures to request an executable stack?
> 
> Microblaze is a soft processor with many configuration options. If we 
> don't use the MMU, there is nothing preventing execution of code on the 
> stack in the MicroBlaze architecture.
>  With the MMU, you have the option to make any page, including the stack 
>  pages, executable or not.
> 
> It is recommended to prevent execution on the stack by defining those 
> pages as non-executable in the MMU. In particular, trampolines would 
> have to be possible to code without execution on the stack

No-MMU configurations are not relevant to a glibc change; the question is 
how things work for configurations using glibc, with the Linux kernel, 
with an MMU.  In such a configuration, for MicroBlaze: (a) is the stack in 
fact executable, now; (b) if it is, what makes it so given the kernel 
default to non-executable (where does my reasoning about what the kernel 
and glibc do go wrong); (c) if it is not executable, do trampolines work 
anyway?

-- 
Joseph S. Myers
jos...@codesourcery.com

RE: Enable no-exec stacks for more targets using the Linux kernel

[Nagaraju Mekala]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Andreas Schwab
> Sent: Wednesday, September 20, 2017 12:19 PM
> To: Joseph Myers 
> Cc: gcc-patches@gcc.gnu.org; l...@redhat.com; dave.ang...@bell.net;
> wil...@tuliptree.org; ea...@eagercon.com
> Subject: Re: Enable no-exec stacks for more targets using the Linux kernel
> 
> On Sep 19 2017, Joseph Myers  wrote:
> 
> > I've sent a glibc patch
> > .  I think
> > the key questions for architecture experts now are: on each of those
> > three architectures, do trampolines ever require executable stacks,
> > and, if they do, how does this work at present when the kernel
> > defaults to non-executable and my understanding at
> >  would be
> > that glibc would only make thread stacks executable on those
> > architectures, not the main process stacks, and GCC will never
> > generate an explicit marker on those architectures to request an executable
> stack?
> 
> For ia64 on linux there is EF_IA_64_LINUX_EXECUTABLE_STACK to request
> executable heap and stack.  But since ia64 uses function descriptors,
> trampolines never need that.
> 
> Andreas.
Sorry somehow mail thread was missed in my earlier mail.
Resending the same reply again:
Microblaze is a soft processor with many configuration options.
If we don't use the MMU, there is nothing preventing execution of code on the 
stack in the MicroBlaze architecture.
 With the MMU, you have the option to make any page, including the stack pages, 
executable or not.

It is recommended to prevent execution on the stack by defining those pages as 
non-executable in the MMU. 
In particular, trampolines would have to be possible to code without execution 
on the stack

Thanks,
Nagaraju

> --
> Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196
> BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7 "And now for something
> completely different."

Re: Enable no-exec stacks for more targets using the Linux kernel

[Andreas Schwab]

On Sep 19 2017, Joseph Myers  wrote:

> I've sent a glibc patch 
> .  I think the 
> key questions for architecture experts now are: on each of those three 
> architectures, do trampolines ever require executable stacks, and, if they 
> do, how does this work at present when the kernel defaults to 
> non-executable and my understanding at 
>  would be that 
> glibc would only make thread stacks executable on those architectures, not 
> the main process stacks, and GCC will never generate an explicit marker on 
> those architectures to request an executable stack?

For ia64 on linux there is EF_IA_64_LINUX_EXECUTABLE_STACK to request
executable heap and stack.  But since ia64 uses function descriptors,
trampolines never need that.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Enable no-exec stacks for more targets using the Linux kernel

[Nagaraju Mekala]

>On Tue, 19 Sep 2017, Andreas Schwab wrote:

> >On Sep 18 2017, Joseph Myers  wrote:
> >
> > Building glibc for many different configurations and running the
> > compilation parts of the testsuite runs into failures of the
> > elf/check-execstack test for hppa, ia64 and microblaze.
> >
>> ia64 is non-execstack by default, so it doesn't need any marking.  The
>> same is true for every architecture that doesn't override
>> elf_read_implies_exec, which includes microblaze and hppa.

> Thanks for the explanation.

> I've sent a glibc patch 
> .  I think the 
>key questions for architecture experts now are: on each of those three 
>architectures, do trampolines ever require executable stacks, and, if they 
>do, how does this work at present when the kernel defaults to 
>non-executable and my understanding at 
> would be that 
>glibc would only make thread stacks executable on those architectures, not 
>the main process stacks, and GCC will never generate an explicit marker on 
>those architectures to request an executable stack?

Microblaze is a soft processor with many configuration options.
If we don't use the MMU, there is nothing preventing execution of code on the 
stack in the MicroBlaze architecture.
 With the MMU, you have the option to make any page, including the stack pages, 
executable or not.

It is recommended to prevent execution on the stack by defining those pages as 
non-executable in the MMU. 
In particular, trampolines would have to be possible to code without execution 
on the stack

Thanks,
Nagaraju

Re: Enable no-exec stacks for more targets using the Linux kernel

[Joseph Myers]

On Tue, 19 Sep 2017, Andreas Schwab wrote:

> On Sep 18 2017, Joseph Myers  wrote:
> 
> > Building glibc for many different configurations and running the
> > compilation parts of the testsuite runs into failures of the
> > elf/check-execstack test for hppa, ia64 and microblaze.
> 
> ia64 is non-execstack by default, so it doesn't need any marking.  The
> same is true for every architecture that doesn't override
> elf_read_implies_exec, which includes microblaze and hppa.

Thanks for the explanation.

I've sent a glibc patch 
.  I think the 
key questions for architecture experts now are: on each of those three 
architectures, do trampolines ever require executable stacks, and, if they 
do, how does this work at present when the kernel defaults to 
non-executable and my understanding at 
 would be that 
glibc would only make thread stacks executable on those architectures, not 
the main process stacks, and GCC will never generate an explicit marker on 
those architectures to request an executable stack?

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Enable no-exec stacks for more targets using the Linux kernel

[Michael Eager]

On 09/19/2017 12:17 AM, Andreas Schwab wrote:

On Sep 18 2017, Joseph Myers  wrote:


Building glibc for many different configurations and running the
compilation parts of the testsuite runs into failures of the
elf/check-execstack test for hppa, ia64 and microblaze.


ia64 is non-execstack by default, so it doesn't need any marking.  The
same is true for every architecture that doesn't override
elf_read_implies_exec, which includes microblaze and hppa.


This fails because those configurations are not generating
.note.GNU-stack sections to indicate that programs do not need an
executable stack.


This needs to be fixed in glibc.


The requirement that a null .note.GNU-stack section needs to be defined
to indicate that the default stack (i.e., non-executable) is used seems
backward.

I don't have any problem approving the MicroBlaze GCC changes, but, like
Andreas, I think that this is a glibc problem.

--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: Enable no-exec stacks for more targets using the Linux kernel

[Andreas Schwab]

On Sep 18 2017, Joseph Myers  wrote:

> Building glibc for many different configurations and running the
> compilation parts of the testsuite runs into failures of the
> elf/check-execstack test for hppa, ia64 and microblaze.

ia64 is non-execstack by default, so it doesn't need any marking.  The
same is true for every architecture that doesn't override
elf_read_implies_exec, which includes microblaze and hppa.

> This fails because those configurations are not generating
> .note.GNU-stack sections to indicate that programs do not need an
> executable stack.

This needs to be fixed in glibc.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Enable no-exec stacks for more targets using the Linux kernel

[Jim Wilson]

On Mon, 2017-09-18 at 22:03 +, Joseph Myers wrote:
> Thus, I'd like the architecture maintainers to advise on whether any
> such issues apply for their architecture.  If they do, that will
> provide the information needed for a comment on XFAILing the test in
> glibc.  If no such reasons apply for the patch to be problematic, I'd
> like it reviewed for each of those architectures (you may wish to do
> such testing as you see fit; I have *not* run any GCC tests with this
> patch, just tested building glibc and running the compilation tests
> with build-many-glibcs.py).

Unfortunately, I don't have access to ia64 hardware anymore, so I am
not able to verify that this works on hardware.  I would expect that
the patches work, and would recommend that you make the changes, and
then we can back them out later if someone runs into a problem.  It
just looks like an oversight due to lack of ia64 maintenance that this
wasn't done before.

The ia64 changes are OK.

Jim