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

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  <joseph@codesourcery.com>

	* 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  <joseph@codesourcery.com>

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

On Mon, 2017-09-18 at 22:03 +0000, 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

On Sep 18 2017, Joseph Myers <joseph@codesourcery.com> 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.

On 09/19/2017 12:17 AM, Andreas Schwab wrote:
> On Sep 18 2017, Joseph Myers <joseph@codesourcery.com> 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.

On Tue, 19 Sep 2017, Andreas Schwab wrote:

> On Sep 18 2017, Joseph Myers <joseph@codesourcery.com> 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 
<https://sourceware.org/ml/libc-alpha/2017-09/msg00734.html>.  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 
<https://sourceware.org/ml/libc-alpha/2017-09/msg00747.html> 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?

On Sep 19 2017, Joseph Myers <joseph@codesourcery.com> wrote:

> I've sent a glibc patch 
> <https://sourceware.org/ml/libc-alpha/2017-09/msg00734.html>.  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 
> <https://sourceware.org/ml/libc-alpha/2017-09/msg00747.html> 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.

> -----Original Message-----
> From: gcc-patches-owner@gcc.gnu.org [mailto:gcc-patches-
> owner@gcc.gnu.org] On Behalf Of Andreas Schwab
> Sent: Wednesday, September 20, 2017 12:19 PM
> To: Joseph Myers <joseph@codesourcery.com>
> Cc: gcc-patches@gcc.gnu.org; law@redhat.com; dave.anglin@bell.net;
> wilson@tuliptree.org; eager@eagercon.com
> Subject: Re: Enable no-exec stacks for more targets using the Linux kernel
> 
> On Sep 19 2017, Joseph Myers <joseph@codesourcery.com> wrote:
> 
> > I've sent a glibc patch
> > <https://sourceware.org/ml/libc-alpha/2017-09/msg00734.html>.  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
> > <https://sourceware.org/ml/libc-alpha/2017-09/msg00747.html> 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, schwab@suse.de GPG Key fingerprint = 0196
> BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7 "And now for something
> completely different."

On Wed, 20 Sep 2017, Andreas Schwab wrote:

> On Sep 19 2017, Joseph Myers <joseph@codesourcery.com> wrote:
> 
> > I've sent a glibc patch 
> > <https://sourceware.org/ml/libc-alpha/2017-09/msg00734.html>.  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 
> > <https://sourceware.org/ml/libc-alpha/2017-09/msg00747.html> 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.

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

On Wed, Sep 20, 2017 at 12:25:46PM +0000, Joseph Myers wrote:
> On Wed, 20 Sep 2017, Andreas Schwab wrote:
> 
> > On Sep 19 2017, Joseph Myers <joseph@codesourcery.com> wrote:
> > 
> > > I've sent a glibc patch 
> > > <https://sourceware.org/ml/libc-alpha/2017-09/msg00734.html>.  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 
> > > <https://sourceware.org/ml/libc-alpha/2017-09/msg00747.html> 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