Linux + Clang + execstack

[Arthur Eubanks]

Adding the linker flag sounds good.

Opened JDK-8209817.

webrev coming soon.

On Tue, Aug 21, 2018 at 4:14 AM Magnus Ihse Bursie <
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>> 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.
>
> 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),
> >> 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
> >>
>
>