On 2018-09-05 04:06, Martin Buchholz 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/
<http://cr.openjdk.java.net/%7Emartin/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
Just FYI: I'm on a long-term mission to clean up the flag handling in
the entire build. There's a lot of weird stuff going on with the flags,
like "why do we do like this on this platform, and like that on that
platform? shouldn't they be the same?". And most of the time, yes, they
probably should be the same. But at other times, there's a reason they
are different and the difference is a deliberate bug fix. It takes time,
effort and a lot of repository archeology to figure that out.
/Magnus
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 <marti...@google.com
<mailto:marti...@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.bur...@oracle.com
<mailto:magnus.ihse.bur...@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.hol...@oracle.com
<mailto: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
<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/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
<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
<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
