RFR: 8239563 - Reduce public exports in dynamic libraries built from static JDK libraries
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Wed Feb 26 12:31:44 UTC 2020
On 2020-02-26 08:41, David Holmes wrote:
> Hi Bob,
> Adding build-dev.
Thanks for noticing that we were missing, David!
> On 26/02/2020 6:37 am, Bob Vandette wrote:
>> Please review this RFE that alters the visibility of JNI entrypoints
>> to hidden when a shared library
>> is created using static JDK libraries.
>> All JNI entrypoints that exist in JDK static libraries are declared
>> as exported or visible.
>> If a dynamic library is built from these static libraries, we end up
>> with many exported
>> functions that we don't want to provide access to,
>> This RFE will change the definition of JNIEXPORT for libraries built
>> when JNI_STATIC_BUILD
>> is defined. When defined, functions declared with JNIEXPORT will not
>> be exported when
>> linked into shared or dynamic libraries. This will still allow
>> linking of these functions into
>> dynamic libraries but will not export the JDK symbols outside of the
>> shared library.
>> A CSR has been filed
>> (https://bugs.openjdk.java.net/browse/JDK-8239791) to add the
>> define support in jni.h.
> I have reservations about turning this into something we have to
> expose and support, rather than being something totally handled within
> the OpenJDK build system.
I fully agree. The JNI headers are an exported interface. Our internal
build mechanisms have nothing to do there.
> I'm tempted to suggest the header files be adjusted to have:
> #ifndef JNIEXPORT
> <JNIEXPORT basic definitions as they are now >
> and then we define the modified JNIEXPORT via the build system when
> doing a static build.
> Is that feasible?
It's definitely doable, and a far better solution.
A patch something akin to this would be needed:
diff --git a/make/autoconf/flags-cflags.m4 b/make/autoconf/flags-cflags.m4
@@ -709,7 +709,10 @@
# JDK libraries.
if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" =
- STATIC_LIBS_CFLAGS="$STATIC_LIBS_CFLAGS -ffunction-sections
+ STATIC_LIBS_CFLAGS="$STATIC_LIBS_CFLAGS -ffunction-sections \
+ STATIC_LIBS_CFLAGS="$STATIC_LIBS_CFLAGS -DJNIEXPORT="
if test "x$TOOLCHAIN_TYPE" = xgcc; then
# Disable relax-relocation to enable compatibility with older linkers
(With the reservation that I just wrote this on the fly and have not
tested it -- things like quoting might be off. Also, I'm not sure if the
compilers is correct -- it might be the case that all compilers except
Microsoft defines __GNUC__, so maybe the addition of this -D flag might
a separate if statement to cover all our compilers correctly.)
>> In JDK8 the JNI specification and JDK implementation was enhanced to
>> support static JNI libraries
>> but we didn’t consider the issue of exportibility of JNI entrypoint
>> If developers use these static JDK libraries in order to produce a
>> custom shared library, all of the
>> JNIEXPORTS will be exposed by this library even if the developer did
>> not choose to export these.
>> This is a security issue and a potential problem if this library is
>> mixed with other libraries containing
>> these symbols.
More information about the core-libs-dev