java-native-access / java-native-access/jna
libjnidispatch.so exports libffi symbols but shouldn't
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 8.9k
- Forks
- 1.7k
- PR merge metrics
- No merged PRs in 30d
Description
Statically linking one library into another one is potentially dangerous, unless safety precautions are taken. objdump -x reveals, that libjnidispatch.so exports many symbols of libffi. To the best of my knowledge, there is only one symbol namespace. So what happens if another JNI library is loaded which links dynamically to the copy of libffi in /usr/lib? Also, what happens if a library is loaded via JNA, that dynamically links to the copy of libffi in /usr/lib? Names will clash. There will be two copies of libffi in memory, and some symbols will be resolved to the copy of libffi in /usr/lib and others will be resolved to the copy of libffi in libjnidispatch.so.
The solution is to control the list of symbols exported when libjnidispatch.so is linked. Version lists can be used to control the list of exported symbols as follows:
Call the linker with the option --version-script=symbols-gnu.txt and the file symbols-gnu.txt with the following contents:
{
global:
_init;
_fini;
Java_com_sun_*;
local:
*;
};
This will export all symbols starting with Java_com_sun_ and _init/_fini. All libffi symbols will not be exported.
The same applies to OS X, as far as I'm aware. The linker options are a little different. So call the linker with the option -exported_symbols_list symbols-osx.txt and create the file symbols-osx.txt with the following contents:
# OS X does not seem to have _init and _fini
_Java_com_sun_*
A libjnidispatch.so that was created this way will use its own private copy of libffi without exporting libffi symbols into the namespace. Hence, symbols names cannot clash with other libraries.
Please fix this as described above. I hope it works for you.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Locate the native build and linker steps that produce libjnidispatch.so, then inspect its exported symbols with objdump -x. Evaluate the proposed symbols-gnu.txt and symbols-osx.txt version/export lists for the Linux and OS X builds; done means Java entry points remain exported while libffi symbols do not.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, java, linux, macos
- Domain
- build-system, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100