<div dir="ltr"><div dir="ltr">Hi Florian,<div><br></div><div>Thanks for looking into this!</div><div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 13, 2023 at 1:58 AM Florian Weimer <<a href="mailto:fweimer@redhat.com">fweimer@redhat.com</a>> wrote:<br></div><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>
> 1. The executable image (see slide #10 ofa [1]) consists of three<br>
> sections: the ELF executable section (see slide #14), the JDK runtime<br>
> section (see slide #20, #21) and the JAR section (see slide #22).<br>
<br>
These sections are not ELF sections, right?<br></blockquote><div><br></div><div>Just to clarify that the ELF sections you referred to in the above are the sections within an ELF file (e.g. <a href="https://manpages.debian.org/stretch/manpages/elf.5.en.html">https://manpages.debian.org/stretch/manpages/elf.5.en.html</a>), if my understanding is correct. The sections described for a hermetic Java image are indeed not ELF sections in that sense. An ELF file as a whole is encapsulated in the hermetic image at the beginning. We can use a better name (if ELF section may cause any confusions), e.g. executable section, to describe the section containing the ELF file.</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>
> 2. The Java launcher executable is statically linked with Hotspot/JDK<br>
> natives and application JNI natives (see slide #15 - #18).<br>
<br>
Doesn't this make the resulting executable non-distributable in almost<br>
all cases, for licensing reasons?  (Hotspot is under the GPL, version 2,<br>
most open-source Java libraries use the Apache license, version 2.0, and<br>
those two are generally considered incompatible.)  At least for those<br>
developers who do not have special licensing arrangements with Oracle<br>
and thus receive OpenJDK under the default terms (including the assembly<br>
exception, but it doesn't seem to help here because it only extends to<br>
OpenJDK components).<br></blockquote><div><br></div><div>Those are good questions. I have to admit that I'm not the appropriate one equipped with the right set of knowledge to answer these questions. This mailing list may not be the proper forum for the topic either. It's probably a good idea to seek the right set of experts and channels for discussions and possible solutions. </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>
[from further down the thread]<br>
<br>
> Yeah, the loadLibrary and friends need to be able look up built-in<br>
> libraries in the executable (within the image ELF section). The<br>
> existing JDK code is already able to handle built-in libraries<br>
> (partially). Please see more details for built-in native support in<br>
> earlier comments.<br>
<br>
I believe that will require a custom glibc patch that has not been<br>
upstreamed.  I think Google's approach is here:<br>
<br>
  <<a href="https://sourceware.org/git/?p=glibc.git;a=blob;f=dlfcn/dlopen.c;h=faf7a48ea71df186b3581235bffcc7a3692f1325;hb=refs/heads/google/grte/v5-2.27/master#l95" rel="noreferrer" target="_blank">https://sourceware.org/git/?p=glibc.git;a=blob;f=dlfcn/dlopen.c;h=faf7a48ea71df186b3581235bffcc7a3692f1325;hb=refs/heads/google/grte/v5-2.27/master#l95</a>><br></blockquote><div><br></div><div>The loadLibrary work for built-in native libraries (with JDK static support) does not require the glibc patch for dlopen_with_offset. <br></div><div><br></div><div>During the investigation, we evaluated different approaches and I prototyped the alternative approach (slide #18 in <a href="http://cr.openjdk.java.net/~jiangli/hermetic_java.pdf">http://cr.openjdk.java.net/~jiangli/hermetic_java.pdf</a>) using dlopen_with_offset, before looking into the JDK static support. dlopen_with_offset would be needed if the DSOs (not statically linked with the executable) were embedded within an image. We decided not to go with that due to several considerations. The main ones include:</div><div><br></div><div>- dlopen_with_offset has not landed in glibc, and there is no plan to do so AFAIK</div><div>- When a shared library is embedded in an executable image (as illustrated in slide #18 in <a href="http://cr.openjdk.java.net/~jiangli/hermetic_java.pdf">http://cr.openjdk.java.net/~jiangli/hermetic_java.pdf</a>), there are issues for the existing standard tools (e.g. perf) to identify the build ID for mapping the correct symbol file associated with the DSO. This's the bigger reason why we did not choose file embedded DSOs. Happy to provide additional details from the investigation on this, if you are interested.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The offset argument is then threaded through the entire code, e.g.:<br>
<br>
  <<a href="https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-open.c;h=178270ca1554c1a81db794fb110a962693839887;hb=refs/heads/google/grte/v5-2.27/master#l539" rel="noreferrer" target="_blank">https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-open.c;h=178270ca1554c1a81db794fb110a962693839887;hb=refs/heads/google/grte/v5-2.27/master#l539</a>><br>
<br>
There is a different proposed glibc interface for this:<br>
<br>
  [PATCH v2 2/2] dlfcn,elf: implement dlmem() function [BZ #11767]<br>
  <<a href="https://sourceware.org/pipermail/libc-alpha/2023-February/145476.html" rel="noreferrer" target="_blank">https://sourceware.org/pipermail/libc-alpha/2023-February/145476.html</a>><br>
<br>
Maybe you could check if that interface could serve your needs as well?<br></blockquote><div><br></div><div>Thanks for pointing to dlmem(). So it looks like we could read the DSO into a buffer then load with dlmem(). Cool! The build ID and symbol file mapping could still be problematic?</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>