Linux + Clang + execstack
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Wed Sep 5 06:50:04 UTC 2018
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.bursie at oracle.com <mailto: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>
> <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
> <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
>
>
>
More information about the hotspot-dev
mailing list