On 2018-09-05 01:01, Martin Buchholz 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...
For the gcc toolchain this can not be the case:
# Minimum supported linker versions, empty means unspecified
TOOLCHAIN_MINIMUM_LD_VERSION_gcc="2.18"
We make sure we have an ld that supports the basic flags we assume.
We can add a similar check for the clang toolchain, if you want.
Mixing and matching compilers and linkers willy-nilly is not a supported
build option, and there's no point in adding extra guards against such a
thing. If you do that, and it turns out your build ended up broken,
tough sh*t.
So I'll insist that adding the linker flag is sufficient to make sure
this works, and that modifying the .s files are not necessary and will
provide no benefit.
/Magnus
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
