RFR: 8239563 - Reduce public exports in dynamic libraries built from static JDK libraries

[David Holmes]

Hi Bob,

Adding build-dev.

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.
> 
> RFE:
> 
> https://bugs.openjdk.java.net/browse/JDK-8239563
> 
> WEBREV:
> 
> http://cr.openjdk.java.net/~bobv/8239563/webrev.00/
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8239791
> 
> 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 JNI_STATIC_BUILD
> 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'm tempted to suggest the header files be 
adjusted to have:

     #ifndef JNIEXPORT
     <JNIEXPORT basic definitions as they are now >
     #endif

and then we define the modified JNIEXPORT via the build system when 
doing a static build.

Is that feasible?

Thanks,
David

> BACKGROUND:
> 
> 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 symbols.
> 
>    https://bugs.openjdk.java.net/browse/JDK-8005716
> 
> 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.
> 
> Bob.
> 
> 
>