JVM default library path includes system folders

[fzakaria]

Describe the bug
I encountered this bug when trying to use JNR that does FFI.
The particular call in general was the equivalent dlopen on the libc library and resolving to the system one which would cause a SIGSEGV.

Digging into the source some more, you discover that Java sets a default value for java.library.path if it's not explicitly set.

#ifndef OVERRIDE_LIBPATH
  #if defined(AMD64) || (defined(_LP64) && defined(SPARC)) || defined(PPC64) || defined(S390)
    #define DEFAULT_LIBPATH "/usr/lib64:/lib64:/lib:/usr/lib"
  #else
    #define DEFAULT_LIBPATH "/lib:/usr/lib"
  #endif
#else
  #define DEFAULT_LIBPATH OVERRIDE_LIBPATH
#endif

https://github.com/openjdk/jdk/blob/50357d136a775872999055bef61057b884d80693/src/hotspot/os/linux/os_linux.cpp#L413

Adding system libraries (i.e. /usr/lib) breaks/invalidates the hermetic invariant needed by Nix.
These library paths are also searched first before those set in the DT_RUNPATH of the ELF header as documented.

I suggest the OVERRIDE_LIBPATH is either set to empty string maybe or even the contents of the ELF RUNPATH header itself.

To Reproduce
I was using JRuby which makes it easy to reproduce by using a gem which ultimately calls the JNR FFI.
(The following reproduction results in the SIGSEGGV)

gem install macaddr
jruby -e "require 'macaddr'; require 'jruby/path_helper'; puts Mac.addr"

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000000000680, pid=3229039, tid=0x00007ff8c5834640
#
# JRE version: OpenJDK Runtime Environment (8.0_265) (build 1.8.0_265-ga)
# Java VM: OpenJDK 64-Bit Server VM (25.265-bga mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  0x0000000000000680

Expected behavior
Expected behavior is for the FFI call to work! This can be resolved by setting java.library.path to the correct lib.

export JAVA_TOOL_OPTIONS=-Djava.library.path=/nix/store/bdf8iipzya03h2amgfncqpclf6bmy3a1-glibc-2.32/lib
❯ jruby -e "require 'macaddr'; require 'jruby/path_helper'; puts Mac.addr"
Picked up JAVA_TOOL_OPTIONS: -Djava.library.path=/nix/store/bdf8iipzya03h2amgfncqpclf6bmy3a1-glibc-2.32/lib
Picked up JAVA_TOOL_OPTIONS: -Djava.library.path=/nix/store/bdf8iipzya03h2amgfncqpclf6bmy3a1-glibc-2.32/lib
02:42:0a:fe:32:3c

NOTE: I could not merely set LD_LIBRARY_PATH because that would apply to everything in my nix-shell.
Furthermore, wrapping java is somewhat tedious, JAVA_TOOL_OPTIONS seemed pragmatic for now.

Notify maintainers
@doronbehar @roberth @manveru

Metadata

 - system: `"x86_64-linux"`
 - host os: `Linux 5.7.17-1rodete4-amd64, Debian GNU/Linux, noversion`
 - multi-user?: `no`


 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.7`
 - channels(fmzakari): `"home-manager, nixpkgs-20.09pre237891.f9eba87bf03"`
 - nixpkgs: `/home/fmzakari/.nix-defexpr/channels/nixpkgs`

Maintainer information:
All JDK derivations

[fzakaria]

If you are curious for the JNR call that loads the C library: https://github.com/jnr/jnr-netdb/blob/master/src/main/java/jnr/netdb/NativeServicesDB.java#L78

            LibServices lib;
            if (os.equals(WINDOWS)) {
                Map<LibraryOption, Object> options = new HashMap<LibraryOption, Object>();
                options.put(LibraryOption.CallingConvention, CallingConvention.STDCALL);
                lib = Library.loadLibrary(LibServices.class, options, "Ws2_32");

            } else {
                String[] libnames = os.equals(SOLARIS)
                    ? new String[] { "socket", "nsl", "c" }
                    : new String[] { "c" };

                if (os.equals(LINUX)) {
                    lib = Library.loadLibrary(LinuxLibServices.class, libnames);
                } else {
                    lib = Library.loadLibrary(LibServices.class, libnames);
                }
            }

[roberth]

I suggest the OVERRIDE_LIBPATH is either set to empty string maybe or even the contents of the ELF RUNPATH header itself.

OVERRIDE_LIBPATH is not sufficient, because it still hardcodes SYS_EXT_DIR/lib, which is somewhere in /usr.
We'll need a patch. This also means we might as well write C code to get the right rpath value, even when re-set.
Although less useful, I'd be ok with a patch that just makes it "". At least that will give a somewhat useful error message instead of a crash.

It seems like OVERRIDE_LIBPATH was designed for cases like ours. Setting it to a static rpath value is tricky because that way we're duplicating it in a way that can't be re-set later. It must be a statically known value. So I'd go with the empty value.

[fzakaria]

@roberth I'm hoping (haven't tested) that with an empty OVERRIDE_LIBPATH the DT_RUNPATH at least will be searched for.
Do you want to work on this change together ? I don't have a lot of experience yet with the JDK derivation (8.nix etc..)

[roberth]

@fzakaria I don't have a lot of experience with that either, but I do implement RubberDuck and I'm happy to review Nix+Java ecosystem stuff.

[fzakaria]

Tagging @volth who seems to do a lot of JVM Java work as well.

[roberth]

Reopening: more versions to be done

[stale]

I marked this as stale due to inactivity. → More info

[roberth]

• OpenJDK 8: jdk8: Remove default java.library.path #123708
• OpenJDK 11: openjdk11: remove default library path #127106
• OpenJDK 17

[ghost]

why does openjdk 17 not have a mr?

[asbachb]

@m911t Do you have a specific problem? With the example above I could not reproduce the jvm crash.

[ghost]

@asbachb sorry, i thought i was hitting this bug, but turns out that the bug i hit is different

[asbachb]

@roberth Is there a way to reproduce this issue for openjdk17? Otherwise I'd propose to close the issue.

[roberth]

why does openjdk 17 not have a mr?

Afaict, it has not been written yet.

With the example above I could not reproduce the jvm crash.

You may not have the "right" libraries in /usr to make it crash.

Is there a way to reproduce this issue for openjdk17?

I don't think we need a reproducer. We know that the unpatched behavior is bad, and it is highly unlikely that upstream's behavior changes, because the rest of the world depends on it.

@fzakaria did you have a specific reason not to patch OpenJDK 17? Could you patch it?

[asbachb]

That patch does not seem to be too complicated. I could prepare it, but I'd feel better if I had some use case to test if the patch is working.

[fzakaria]

I mostly just forgot about it sadly. 😔 Some other stuff picked up and it kind of fell by the wayside sorry about that.

…

On Thu, Jul 28, 2022, 2:19 AM Benjamin Asbach ***@***.***> wrote: That patch does not seem to be too complicated. I could prepare it, but I'd feel better if I had some use case to test if the patch is working. — Reply to this email directly, view it on GitHub <#103493 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAETXDWQHL3KUTADJAS2WCTVWJGDTANCNFSM4TSNVH5A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[abathur]

Closing since it looks like the last bit of this was fixed by #183760. Happy to reopen if I'm mistaken.