Make ELF loading respect program header virtual addresses for non-PIE binaries

[cshung]

Summary

For non-PIE (ET_EXEC) ELF binaries, the guest page table now maps the code region at the ELF's declared virtual address rather than identity-mapping it at the GPA. This allows statically-linked binaries with a fixed load address (e.g., --image-base=0x200000) to execute correctly.

Problem

Previously, Hyperlight assumed code GVA == code GPA (identity mapping). Non-PIE binaries that declare a non-zero base virtual address (via program header p_vaddr) would triple-fault because the guest CPU jumped to the ELF's declared entrypoint VA, which wasn't mapped in the page tables.

Solution

• Compute code_virt_base from the ELF's lowest LOAD segment p_vaddr
• For non-PIE (base_va > 0): map code at the declared VA in the guest page tables
• For PIE (base_va == 0): preserve existing identity mapping behavior (with assertion to guard the invariant)
• Compute entrypoint as code_virt_base + (entrypoint_va - base_va)

The fix leverages the existing Mapping struct's support for phys_base != virt_base — no changes to the page table code itself.

Testing

• New non_pie_guest_hello_world integration test exercises full guest lifecycle (init, COW, function call, return value) with a non-PIE simpleguest built at --image-base=0x200000
• All existing PIE guest tests continue to pass (identity mapping preserved)
• Tested on Windows/WHP and Linux/KVM

Build infrastructure

• Added build-rust-guests-non-pie Justfile targets
• Non-PIE build runs first in guests recipe to avoid clobbering normal guest binaries
• Added simple_guest_non_pie_as_string() test helper

Contributes to: #1408

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

This PR adds support for running and testing non-PIE Rust guest binaries, including updating snapshot virtual-address mapping so non-PIE guests execute at their declared ELF virtual addresses.

Changes:

• Add a helper in hyperlight_testing to locate the non-PIE simpleguest binary.
• Update snapshot mapping/entrypoint calculation to support non-identity VA mappings for non-PIE code regions.
• Add a new integration test and build automation (Justfile) to produce and run a non-PIE guest.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

File	Description
src/hyperlight_testing/src/lib.rs	Adds path helper(s) for locating non-PIE Rust guest binaries.
src/hyperlight_host/tests/integration_test.rs	Adds an integration test that boots and calls into a non-PIE guest.
src/hyperlight_host/src/sandbox/snapshot/mod.rs	Adjusts snapshot mappings and entrypoint VA calculation to support non-PIE guests.
Justfile	Adds tasks to build and stage non-PIE Rust guest artifacts.

[cshung]

Addressed Copilot review feedback:

1. Justfile (RUSTFLAGS on Linux) — Fixed. \RUSTFLAGS\ now prefixes \cargo\ directly after \cd &&\ so the env var applies to the build command.

2. snapshot/mod.rs (virt_base mapping) — No change needed. The code region is a single contiguous block where
   gn.guest_region.start == load_addr\ — there is no offset to lose. The \�ssert_eq!\ is deliberate per codebase convention.

3. snapshot/mod.rs (entrypoint underflow) — Fixed. Now uses \checked_sub\ with a proper error for malformed ELFs.

4. lib.rs (doc says 'elf binary') — No change needed. Hyperlight guests are always ELF regardless of host OS.

[ludfjig]

LGTM. @syntactically could you have a look too

[syntactically]

Thanks for doing this! It looks like it is moving in a good direction. I have a couple of minor suggestions/comments, as well as a bit of an alternative design that you could take (but totally up to you on that one!)

[ludfjig]

LGTM but will once again defer to @syntactically for final review

[syntactically]

This looks good to me, thank you and sorry for the delay reviewing!

I do think that there is one minor move that would make the code a little bit cleaner / better fitting with existing conventions, which I've commented on inline. Feel free to push back with a reason why this code belongs here, though!

[cshung]

All review comments have been addressed. The suggestion to move conflict-check logic into \layout.rs\ (from the Jul 15 review) is implemented in the follow-up PR #1655 via the \code_virt_base()\ method which handles both VA selection and overlap validation.

@syntactically — ready for re-review when you get a chance!

[syntactically]

If you've already done that, I think it would be slightly nice to get it cherry-picked here without the ASLR changes, since I'm not totally sure we are decided on doing ASLR---it has pretty limited benefits for the modal hyperlight use case because one can't (generally) re-slide an image after a snapshot is taken, and in practice almost all images of a given binary are expected to descend from one snapshot.

As I said before I don't feel incredibly strongly though---I will leave the decision up to you.

[syntactically]

It is used by the GDB debug path (\GetCodeSectionOffset\ in \x86_64.rs) to report where the code section lives in guest virtual space. Without it, GDB cannot resolve symbols after snapshot restore. It is also needed for
ead_guest_memory_by_gva\ (tracing feature) to translate GVAs back to physical offsets.

Ah, of course. I think the SandboxMemoryLayout is already accessible in the relevant places and a lot of the information about the layout is already centralised there; could we just move this into that?

Silently relocating other regions would make behavior hard to reason about, and those regions have fixed GPAs that the PEB and guest runtime depend on. I think erroring is the right call here

Well, in the non-PIE mode, those gpas are not independent of the executable, because the code segment is near the bottom of the initial setup snapshot region. So, it's kind of being consistent to move them. However, I don't feel strongly.

[dblnz]

Have you by any chance tried debugging a guest using gdb/lldb to ensure PIE binaries behave correctly when debugged? Also, the same question applies to crashdump.

[cshung]

Yes. The branch has end-to-end tests using the PIE simpleguest binary.

• test_gdb_end_to_end verifies source breakpoint and symbol resolution.
• test_gdb_from_snapshot verifies the same after snapshot restore.
• test_crashdump_gdb_symbols verifies that GDB resolves the saved PC using the core file's AT_ENTRY load bias.
• test_crashdump_gdb_symbols_from_snapshot verifies that path after snapshot restore.

The latest x64 KVM run executed and passed all four tests. The GDB tests also passed on x64 Hyper-V. These were real GDB sessions, not compile-only checks or skipped tests: https://github.com/hyperlight-dev/hyperlight/actions/runs/35659787035

I have not separately exercised LLDB. The GDB and crashdump tests cover the PIE load-address behavior this PR changes.