Hermetic Java (static image packaging/formatting) investigation and proposal

[Florian Weimer]

* Jiangli Zhou:

> We also considered startup-time/install-time extraction. Based on the
> feedback from other language usages in real production, extraction has
> real production challenges in many cases, including (tmpfs) file
> system configuration/management issues, possible security
> vulnerabilities, temp space pollution, extraction conflicts, and
> etc. (thanks to the feedback from other language experts from their
> experiences!). Those make the extraction approach unattractive.

I thought that OpenJDK has its own DSO-from-JAR extractor?

There's memfd_create, which is currently an un-auditable trapdoor to the
world of self-modifying code (although I expect that will be closed off
eventually).  It works even if /tmp, /dev/shm, etc. are all mounted
noexec.

Experimenting with it suggests that GDB doesn't rely on link map data
exclusively.  It gets somewhat confused and doesn't read the symbols:

(gdb) info shared
>From                To                  Syms Read   Shared Object Library
0x00007f00a83a1700  0x00007f00a84f519d  Yes         /lib64/libc.so.6
0x00007f00a85720a0  0x00007f00a85980e5  Yes         /lib64/ld-linux-x86-64.so.2
                                        No          /proc/589166/fd/3

This should work, but it does not. 8-(  Even the non-debugging
ELF symbols are missing.

The dlmem implementation posted to libc-alpha probably has even more
problems.  I'm no longer convinced that the public link map (reachable
via _r_debug) has sufficient information for debuggers.

But if we could fix these issues, the memfd_create approach could be a
viable replacement for extracting DSOs from JAR files (to turn this
slightly more on-topic).

Thanks,
Florian