Linux + Clang + execstack

Magnus Ihse Bursie magnus.ihse.bursie at
Wed Sep 5 06:50:04 UTC 2018

On 2018-09-05 01:01, Martin Buchholz wrote:
> I think we can all agree that passing flags to the linker to ensure 
> non-executable stack is the right thing to do. But there's a question 
> whether *also* adding something to our assembly language source files 
> will be worth doing.  Neither mechanism is sure to work.  For the 
> linker flag, we need to be aware of and test for the presence of the 
> linker flag, but we might be using some other linker...

For the gcc toolchain this can not be the case:
# Minimum supported linker versions, empty means unspecified

We make sure we have an ld that supports the basic flags we assume.

We can add a similar check for the clang toolchain, if you want.

Mixing and matching compilers and linkers willy-nilly is not a supported 
build option, and there's no point in adding extra guards against such a 
thing. If you do that, and it turns out your build ended up broken, 
tough sh*t.

So I'll insist that adding the linker flag is sufficient to make sure 
this works, and that modifying the .s files are not necessary and will 
provide no benefit.


> Similarly, we might end up using some other assembler, or we might 
> need to mark the assembly source file in a different way than "GNU-stack".
> On Tue, Aug 21, 2018 at 4:14 AM, Magnus Ihse Bursie 
> <magnus.ihse.bursie at <mailto:magnus.ihse.bursie at>> 
> wrote:
>     On 2018-08-21 02:03, David Holmes wrote:
>         On 21/08/2018 9:39 AM, Arthur Eubanks wrote:
>             On Mon, Aug 20, 2018 at 4:18 PM David Holmes
>             <david.holmes at <mailto:david.holmes at>
>             <mailto:david.holmes at
>             <mailto:david.holmes at>>> wrote:
>                 Hi Arthur,
>                 cc'ing build-dev as this is currently a build issue.
>                 On 21/08/2018 3:11 AM, Arthur Eubanks wrote:
>                  > Hi,
>                  >
>                  > At Google we're trying to build hotspot on Linux
>             with clang. One
>                 thing that
>                  > happens is that the resulting is stack
>             executable. When
>                 running
>                  > hotspot we get warnings about the stack being
>             executable.
>                  >
>                  > Compiling an assembly file into the final .so
>             results in the
>                 stack being
>                  > executable. In this case the file is
>             linux_x86_64.s. This doesn't
>                 happen
>                  > with gcc because "-Wl,-z,noexecstack" is passed as
>             a hotspot
>                 linker flag
>                  > with gcc in flags-ldflags.m4. When using clang that
>             linker flag isn't
>                  > passed.
>                  >
>                  > Doing something like the solution in
>                  >
>             <>
>                  > fixes the problem without the use of linker flags.
>                 You mean the source code directives for the linker?
>             Sorry, I wasn't specific enough, I meant the flags for the
>             assembler.
>             #if defined(__linux__) && defined(__ELF__)
>             .section        .note.GNU-stack, "", %progbits
>             #endif
>                 I think I prefer to see this handled explicitly in the
>             build as is
>                 currently done. Can we just adjust
>             ./make/autoconf/flags-ldflags.m4 to
>                 pass the linker flags for gcc and clang?
>             I don't mind this solution, but it seems like the right
>             thing to do is to fix things at the source level and
>             remove extra unnecessary linker flags.
>         Personally I see this as source code pollution. The concept of
>         executable stacks has nothing to do with what is being
>         expressed by the source code, or the language used for it.
>         Just my 2c. I'll defer to build folk ... though they are still
>         on vacation at the moment.
>     I agree with David. The executable stack is a build option. Even
>     if you change the source code so the compiler/assember does the
>     right thing, we would still want to keep the compiler option.
>     (Otherwise one day you'll end up with executable stacks due to
>     someone adding a new asm file and forgetting the "magic incantation".)
>     And, since we will keep the compiler option, there seems little
>     point in also adding this stuff to the asm files.
>     To address your concerns on clang: we should reasonably be giving
>     the same options to clang. There is no good reason, except for
>     oversight, that this is not done already. (Cleaning up and
>     unifying the compiler flags is an ongoing, but slowly moving,
>     process.) So the correct fix is to update flags-ldflags.m4.
>     /Magnus
>             I removed "-Wl,-z,noexecstack" from the flags after adding
>             the above assembler flags and is still correctly
>             not stack executable. I don't really mind either way
>             though. Maybe it's good to have an extra safeguard in the
>             linker flags.
>                  > The jtreg test
>             test/hotspot/jtreg/runtime/execstack/
>                  > checks for the stack being executable.
>                  >
>                  > Any thoughts? If there are no objections, I can
>             propose a patch
>                 that works
>                  > for both gcc and clang on Linux. Also, I'm not sure
>             how/if macOS
>                 handles
>                  > this problem given that it uses clang.
>                 We don't seem to handle it at all on OS X. Does OS X
>             prevent executable
>                 stacks itself?
>             A quick search, according to Wikipedia
>             (
>             <>),
>             64-bit executables on macOS aren't stack or heap
>             executable. Not sure if that information is accurate though.
>         Seems to be:
>         <>
>         "macOS and iOS provide two features that can make it harder to
>         exploit stack and buffer overflows: address space layout
>         randomization (ASLR) and a non-executable stack and heap."
>         Cheers,
>         David
>                 David

More information about the hotspot-dev mailing list