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.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>> 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 > >> > >
