RFR: 8354675: Create separate image builder for hermetic

[Jiangli Zhou]

On Thu, Apr 17, 2025 at 9:55 AM Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> On 2025-04-15 16:28, Jiangli Zhou wrote:
>
> On Thu, 10 Apr 2025 16:13:47 GMT, Severin Gehwolf <sgehwolf at openjdk.org> <sgehwolf at openjdk.org> wrote:
>
>
> $ ll -lh ./demo-image
> -rwxr-xr-x. 1 sgehwolf sgehwolf 909M Apr 10 17:36 ./demo-image
> $ strip -g ./demo-image
> $ ll -lh ./demo-image
> -rwxr-xr-x. 1 sgehwolf sgehwolf 50M Apr 10 18:07 ./demo-image
> $ ./demo-image -m mod.example/com.example.demo.Main
> Error occurred during initialization of VM
> Failed setting boot class path.
>
> Yeah, stripping the final image would corrupt the image. The linked launcher executable should be stripped first, then passed to jlink to create the final image. The `build-id` would be the same.
>
> I tried commenting this on a commit, but I guess it is kind of invisible
> there, so let me repeat it here, and expand on it.
>
> The current approach on just "tucking on" the jlink data at the end of the
> binary surprises me. I've always just presumed that the jimage part should
> be stored as an ELF section, so that the entire binary is a complete, valid
> ELF file. I assume that if the jlink data was stored as a proper ELF
> section, the binary would not be destroyed by strip.
>
In the original prototype using the singlejar tool, the jimage, cds
archive, and JAR files are appended after the ELF binary (see
https://cr.openjdk.org/~jiangli/hermetic_java.pdf, slide 10). I basically
followed the same approach in the current prototype using jlink. We have
discussed (a few times) the approach of appending the jimage after the ELF
and recording the jimage start offset and size info at the end of the final
image during the ongoing hermetic Java meetings.

Any particular benefits of making the hermetic Java image as a pure ELF
binary by fitting the jimage as an ELF section, besides being able to run
strip? The launcher executable can be stripped during native linking (e.g.
with -s for ld) then being fed to jlink for final image creation.

Tools like gdb, lldb, perf, nm, etc can work with the final hermetic image
without issue.


> It also surprises me that this approach even works. Is appending arbitrary
> stuff at the end of the file explicitly allowed by the ELF spec? Or is this
> solution dependent on ELF loaders being not so strict? If so, it can break
> with any future update to the dynamic loader...
>
Self-extracting zip archive is a good example of appending data after an
executable (such as an ELF binary on linux).

Another example that I think that's relatvent is FatELF, see
https://icculus.org/fatelf/.  The file format combines multiple ELF
binaries into a single file and can be executed on different architectures.

Thanks,
Jiangli

> /Magnus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20250417/2c32e29b/attachment.htm>