RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v7]

Cheng Jin duke at openjdk.java.net
Tue Oct 12 18:14:54 UTC 2021


On Thu, 3 Jun 2021 20:49:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms.
>> 
>> This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added:
>> 
>> * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader
>> * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified.
>> 
>> Both factories are *restricted*, so they can only be called when `--enable-native-access` is set.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments on shim lib makefile

Just tried with `System.load()` but still ended up with pretty much the same failure given both of them eventually invokes `ClassLoader.loadLibrary` to load the library in which case there is no big difference at this point.

        static {
                System.load("/usr/lib/libc.a");
        }

Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load /usr/lib/libc.a <----
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:1793)
        at java.base/java.lang.System.load(System.java:672)
        at StdLibTest.<clinit>(StdLibTest.java:24)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4316


More information about the security-dev mailing list