checkpoint: embed the restore stub instead of exec'ing its build path

[congwang-mk]

Checkpoint restore only worked on the machine that built sandlock. build.rs compiled the restore stub into cargo's OUT_DIR and baked that absolute path into the crate (env!("RESTORE_STUB_PATH")), so release tarballs, PyPI wheels, and any distro package exec'd a path that does not exist on the user's host and failed with "restore-stub was not built". This blocks shipping sandlock as a distro package.

Fix

• The stub is embedded with include_bytes! and handed to the child as a sealed memfd at fd 6 (STUB_FD, next to the existing CTRL/READY/GO fds).
• The child runs it with execveat(fd, "", AT_EMPTY_PATH) through a new ChildEntry::ExecFd. No path is resolved, so the policy no longer gets a read grant on the stub, and restore does not depend on /proc inside the sandbox.
• The memfd is created with MFD_EXEC (see below), so a vm.memfd_noexec=1 host does not seal it non-executable.
• The stub closes fd 6 with the other control fds before reopening the checkpoint's fd table.
• On arches without a restore engine, build.rs writes an empty placeholder so include_bytes! compiles; an empty stub reports restore as unavailable.

Chroot: exec by fd

The stub now reaches the child as a memfd, which has no path inside a chroot, and the chroot exec handler confined every exec to a path in the root. So execveat(fd, "", AT_EMPTY_PATH) failed with EACCES, both for restore and for any chroot workload calling fexecve on a memfd. Restore under chroot had only worked when the build directory happened to be visible inside the root.

The second commit makes the handler take the image from the guest's own fd:

• An fd to a file inside the root goes through the path policy, as a path-based exec does.
• Any other fd (a memfd, or a file inherited from the host) must be held readable. The guest could then copy the bytes into its own memfd anyway, so exec grants nothing new, and Landlock still gates EXECUTE on any real file.
• The image is read through a fresh open file description, because the guest's shares its offset and the PT_INTERP scan seeks.

vm.memfd_noexec=1

The third commit adds memfd_create_exec, which asks for MFD_EXEC and retries with plain flags on kernels before 6.3 that reject it with EINVAL (their memfds are always executable). Both exec'd memfds use it: the restore stub, and the chroot exec handler's PT_INTERP-patched copy of dynamic binaries. The latter was created with flags 0, so on a vm.memfd_noexec=1 host every dynamic binary in a chroot failed to exec, on main too. At vm.memfd_noexec=2 memfd exec is forbidden outright, and restore and chroot dynamic exec still fail there. This could not be tested locally (changing the sysctl needs root).

Testing

• test_restore_resumes_inside_a_chroot checkpoints and restores a program in a real rootfs; test_chroot_fexecve_runs_an_image_held_by_fd covers fexecve from an in-root file fd and from a memfd (new fexecve subcommand in rootfs-helper). Without the second commit, chroot restore and the memfd case fail with EACCES.
• New unit test checks that the stub memfd is write-sealed and holds the embedded bytes; the synthetic-image stub tests now exec it through execveat like restore does.
• Rust --lib (888), integration (519 + 13), FFI restore (3), and Python (430, excluding the guard tests) all pass locally.
• With the build-tree out/restore-stub moved away, the Python restore tests still pass, which simulates an installed binary.

🤖 Generated with Claude Code