Linux + Clang + execstack

Wed Sep 5 02:22:16 UTC 2018

> On Sep 4, 2018, at 7:06 PM, Martin Buchholz <martinrb at google.com> wrote:
> 
> 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?

I like to think that our .s files are effectively incomplete, and that adding the annotations makes them less incomplete. I am, however, not emotionally attached to this so I’ll leave it up to you and others to decide what to do with it :)

(it would also be interesting to see if we can perhaps move some of the .s code to C++ instead)

Cheers,
Mikael

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