<div dir="ltr"><div dir="ltr">On Tue, Feb 14, 2023 at 1:37 AM Florian Weimer <<a href="mailto:fweimer@redhat.com">fweimer@redhat.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* Jiangli Zhou:<br>
<br>
> We also considered startup-time/install-time extraction. Based on the<br>
> feedback from other language usages in real production, extraction has<br>
> real production challenges in many cases, including (tmpfs) file<br>
> system configuration/management issues, possible security<br>
> vulnerabilities, temp space pollution, extraction conflicts, and<br>
> etc. (thanks to the feedback from other language experts from their<br>
> experiences!). Those make the extraction approach unattractive.<br>
<br>
I thought that OpenJDK has its own DSO-from-JAR extractor?<br></blockquote><div><br></div><div>Do you have a pointer to the feature?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
There's memfd_create, which is currently an un-auditable trapdoor to the<br>
world of self-modifying code (although I expect that will be closed off<br>
eventually). It works even if /tmp, /dev/shm, etc. are all mounted<br>
noexec.<br>
<br>
Experimenting with it suggests that GDB doesn't rely on link map data<br>
exclusively. It gets somewhat confused and doesn't read the symbols:<br>
<br>
(gdb) info shared<br>
From To Syms Read Shared Object Library<br>
0x00007f00a83a1700 0x00007f00a84f519d Yes /lib64/libc.so.6<br>
0x00007f00a85720a0 0x00007f00a85980e5 Yes /lib64/ld-linux-x86-64.so.2<br>
No /proc/589166/fd/3<br>
<br>
This should work, but it does not. 8-( Even the non-debugging<br>
ELF symbols are missing.<br>
<br>
The dlmem implementation posted to libc-alpha probably has even more<br>
problems. I'm no longer convinced that the public link map (reachable<br>
via _r_debug) has sufficient information for debuggers.<br>
<br>
But if we could fix these issues, the memfd_create approach could be a<br>
viable replacement for extracting DSOs from JAR files (to turn this<br>
slightly more on-topic).<br></blockquote><div><br></div><div>AFAIK, there were some investigations/experiments done by others in Google on memfd_create for supporting file embedded DSOs (not Java specific). The concerns from the tooling side (about file offsets) still seem to be applicable with this approach. <br></div><div><br></div><div>Best,</div><div>Jiangli</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks,<br>
Florian<br>
<br>
</blockquote></div></div>