On 21/08/2018 4:29 PM, Mikael Vidstedt wrote:
On Aug 20, 2018, at 5:03 PM, David Holmes <david.hol...@oracle.com
<mailto:david.hol...@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.hol...@oracle.com
<mailto:david.hol...@oracle.com> <mailto:david.hol...@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
