Linux + Clang + execstack

[David Holmes]

On 21/08/2018 4:29 PM, Mikael Vidstedt wrote:
>> On Aug 20, 2018, at 5:03 PM, David Holmes <david.holmes at oracle.com 
>> <mailto:david.holmes at oracle.com>> 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> <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.
> 
> Control question: why doesn’t the compiled .cpp files provoke the 
> executable stack problem? After all, they’re also an assembly file 
> somewhere on the way from .cpp to object file.

Either gcc does something or else ld does something based on the 
noexecstack build flags we use.

> I’m guessing it’s because gcc does insert the .note.GNU-stack directive. 
> If so, it seems reasonable to me to require/expect our assembly files to 
> include that directive as well?

If gcc inserts something in a .o from a .cpp file then I would expect 
the assembler (gas? or still gcc?) to insert something in a .o from a .s 
file.

David

> Cheers,
> Mikael
> 
>>
>>> 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/execstack/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/Security/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
>