Linux + Clang + execstack

Wed Sep 5 02:06:53 UTC 2018

Here's Arthur's patch:

8205457: gcc and clang should use the same ld flags
http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/
https://bugs.openjdk.java.net/browse/JDK-8205457

This applies -Wl,-z,noexecstack uniformly to all linker invocations where
applicable.

TODO:
All ld flags on Linux should be treated equally by gcc and clang
The test TestCheckJDK and supporting infrastructure should stop advertising
itself as only dealing with libraries.
Maybe add GNU-stack annotations to all the Linux .s files as well?

On Tue, Sep 4, 2018 at 4:01 PM, Martin Buchholz <martinrb at google.com> 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... 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 oracle.com> 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 oracle.com
>>>> <mailto:david.holmes at oracle.com>> 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 libjvm.so 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
>>>>      > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
>>>>      > 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 libjvm.so 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/exe
>>>> cstack/TestCheckJDK.java
>>>>      > 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 (https://en.wikipedia.org/wiki
>>>> /Executable_space_protection#macOS), 64-bit executables on macOS
>>>> aren't stack or heap executable. Not sure if that information is accurate
>>>> though.
>>>>
>>>
>>> Seems to be:
>>>
>>> https://developer.apple.com/library/archive/documentation/Se
>>> curity/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html
>>>
>>> "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
>>>>
>>>>
>>
>