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

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

[Joseph Myers]

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.

This fails because those configurations are not generating
.note.GNU-stack sections to indicate that programs do not need an
executable stack.  This patch fixes GCC to generate those sections on
those architectures (when configured for a target using the Linux
kernel), as it does on other architectures, together with adding that
section to libgcc .S sources, with the same code as used on other
architectures (or a variant using "#ifdef __linux__" instead of the
usual "#if defined(__ELF__) && defined(__linux__)" for microblaze, as
that configuration doesn't use elfos.h and so doesn't define __ELF__).

This suffices to eliminate that glibc test failure.  (For hppa, the
compilation parts of the glibc testsuite still fail because of the
separate elf/check-textrel failure.)  Now, there are some possible
reasons why a change such as this could be incorrect, and I don't know
enough about the architectures in question to rule them out: (a) if
the hardware architecture does not actually support the page
permissions required for no-exec stacks, (b) if, as on MIPS,
additional architecture-specific work elsewhere in the toolchain or
kernel would be needed for no-exec stacks to work, or (c) if in fact
one of the libgcc functions I've marked for no-exec stacks somehow
needs an executable stack.

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).

gcc:
2017-09-18  Joseph Myers  

* config/ia64/linux.h (TARGET_ASM_FILE_END): New macro.
* config/microblaze/linux.h (TARGET_ASM_FILE_END): Likewise.
* config/pa/pa.h (NEED_INDICATE_EXEC_STACK): Likewise.
* config/pa/pa-linux.h (NEED_INDICATE_EXEC_STACK): Likewise.
* config/pa/pa.c (pa_hpux_file_end): Rename to pa_file_end.
Define unconditionally, with [ASM_OUTPUT_EXTERNAL_REAL]
conditionals inside the function instead of around it.  Call
file_end_indicate_exec_stack if NEED_INDICATE_EXEC_STACK.
(TARGET_ASM_FILE_END): Define unconditionally to pa_file_end.

libgcc:
2017-09-18  Joseph Myers  

* config/ia64/crtbegin.S, config/ia64/crtend.S,
config/ia64/crti.S, config/ia64/crtn.S, config/ia64/lib1funcs.S,
config/microblaze/crti.S, config/microblaze/crtn.S,
config/microblaze/divsi3.S, config/microblaze/moddi3.S,
config/microblaze/modsi3.S, config/microblaze/muldi3_hard.S,
config/microblaze/mulsi3.S,
config/microblaze/stack_overflow_exit.S,
config/microblaze/udivsi3.S, config/microblaze/umodsi3.S,
config/pa/milli64.S: Add .note.GNU-stack section.

Index: gcc/config/ia64/linux.h
===
--- gcc/config/ia64/linux.h (revision 252935)
+++ gcc/config/ia64/linux.h (working copy)
@@ -81,3 +81,5 @@ do {  \
 
 /* Define this to be nonzero if static stack checking is supported.  */
 #define STACK_CHECK_STATIC_BUILTIN 1
+
+#define TARGET_ASM_FILE_END file_end_indicate_exec_stack
Index: gcc/config/microblaze/linux.h
===
--- gcc/config/microblaze/linux.h   (revision 252935)
+++ gcc/config/microblaze/linux.h   (working copy)
@@ -57,3 +57,5 @@
 /* For the microblaze-*-linux* subtarget.  */
 #undef TARGET_OS_CPP_BUILTINS
 #define TARGET_OS_CPP_BUILTINS() GNU_USER_TARGET_OS_CPP_BUILTINS()
+
+#define TARGET_ASM_FILE_END file_end_indicate_exec_stack
Index: gcc/config/pa/pa-linux.h
===
--- gcc/config/pa/pa-linux.h(revision 252935)
+++ gcc/config/pa/pa-linux.h(working copy)
@@ -141,3 +141,6 @@ along with GCC; see the file COPYING3.  If not see
 #define HAVE_sync_compare_and_swaphi 1
 #define HAVE_sync_compare_and_swapsi 1
 #define HAVE_sync_compare_and_swapdi 1
+
+#undef NEED_INDICATE_EXEC_STACK
+#define NEED_INDICATE_EXEC_STACK 1
Index: gcc/config/pa/pa.c
===
--- gcc/config/pa/pa.c  (revision 252935)
+++ gcc/config/pa/pa.c  (working copy)
@@ -159,9 +159,7 @@ static void pa_hpux64_gas_file_start (void) ATTRIB
 static void pa_hpux64_hpas_file_start (void) ATTRIBUTE_UNUSED;
 static void output_deferred_plabels (void);
 static void output_deferred_profile_counters (void)