Add Linux arm64 sandbox runtime support

[gokwok]

Summary

This PR adds Linux arm64/aarch64 support for sandlock's seccomp-based sandbox
runtime.

The existing implementation assumed the x86_64 Linux syscall ABI in several
places:
syscall numbers, seccomp audit architecture, raw syscall argument registers,
legacy non-*at path syscalls, struct stat layout, ptrace register capture, and
vDSO symbol/stub handling. Those assumptions prevented the runtime and test
suite from working correctly on arm64.

This series makes those paths architecture-aware while preserving the existing
x86_64 behavior.

What Changed

• Add architecture-specific syscall and seccomp ABI definitions.
• Make raw syscall helpers support both x86_64 and arm64 calling conventions.
• Treat legacy path syscalls as optional, since Linux arm64 does not expose
  syscalls such as SYS_open/SYS_stat/SYS_access.
• Use equivalent raw *at syscall ABIs in tests where arm64 lacks legacy path
  syscalls.
• Fix COW filesystem handling on arm64:
  • use native libc::stat layout instead of x86_64 hand-packed stat bytes
  • normalize virtual COW paths
  • virtualize getcwd after chdir into COW-only directories
  • support getdents on upper-layer directory fds
• Add arm64 checkpoint support through PTRACE_GETREGSET.
• Add arm64 vDSO time syscall stubs for deterministic time handling.
• Adjust integration and Python tests so arm64 coverage runs instead of being
  skipped for x86_64-only assumptions.
• Clean up Python test warnings to keep warning-free test runs stable.

Compatibility

The x86_64 behavior is intended to remain unchanged. The arm64 implementation
uses architecture-specific constants and optional syscall registration rather
than hard-coding x86_64-only syscall numbers.

One important ABI difference is that Linux arm64 does not provide several
legacy non-*at path syscalls. For those cases, this PR tests the equivalent raw
*at ABI, for example openat(AT_FDCWD, ...), instead of pretending SYS_open
exists on arm64.

Test Plan

Verified on arm64（macos apple container / orb linux machine):

• cargo integration tests pass
• Python test suite passes
• Python test suite also passes with warnings treated as errors

The final patch series keeps the x86_64 assumptions isolated behind the new
architecture layer and keeps the existing x86_64 syscall paths intact.

[congwang-mk]

Thanks for the PR!

CowState.virtual_cwds is keyed by pid and entries are never removed. Scope is bounded to a single Sandbox::run() (state is dropped when the sandbox exits), so this isn't a long-lived leak — but within one run it's a latent correctness bug:

1. Child pid X chdirs into a COW-only dir → virtual_cwds[X] = "/workdir/newdir".
2. Child X exits. The supervisor has no pid-exit hook that removes the entry (handle_wait at resource.rs:71 only decrements proc_count; it doesn't see which pid was reaped).
3. Kernel reuses pid X for a new child that never chdir'd.
4. That child's getcwd / path-resolving COW handlers now return the stale virtual cwd from step 1.

Low probability (short-lived sandboxes, fresh PID namespace, would need to wrap the PID space), but the failure mode is silent and hard to debug if it ever hits. CowState.dir_cache has the same shape and is only cleaned on fd reuse, not pid exit — so a fix should probably cover both.

BTW, the Rust tests job failed on this PR: https://github.com/multikernel/sandlock/actions/runs/24758554033/job/72484409985 — please take a look and get it green before this merges.

[gokwok]

Thanks for the PR!

CowState.virtual_cwds is keyed by pid and entries are never removed. Scope is bounded to a single Sandbox::run() (state is dropped when the sandbox exits), so this isn't a long-lived leak — but within one run it's a latent correctness bug:

1. Child pid X chdirs into a COW-only dir → virtual_cwds[X] = "/workdir/newdir".
2. Child X exits. The supervisor has no pid-exit hook that removes the entry (handle_wait at resource.rs:71 only decrements proc_count; it doesn't see which pid was reaped).
3. Kernel reuses pid X for a new child that never chdir'd.
4. That child's getcwd / path-resolving COW handlers now return the stale virtual cwd from step 1.

Low probability (short-lived sandboxes, fresh PID namespace, would need to wrap the PID space), but the failure mode is silent and hard to debug if it ever hits. CowState.dir_cache has the same shape and is only cleaned on fd reuse, not pid exit — so a fix should probably cover both.

BTW, the Rust tests job failed on this PR: https://github.com/multikernel/sandlock/actions/runs/24758554033/job/72484409985 — please take a look and get it green before this merges.

Thanks for the detailed review!

I've pushed the fixes to this PR branch.

I fixed both issues in the latest update:

1. The stale per-pid COW state issue is addressed by keying COW per-process state with a stable pid identity instead of the raw pid alone. The key now includes both pid and the process start time from /proc//stat. This covers both CowState.virtual_cwds and CowState.dir_cache, and stale entries for a reused numeric pid are pruned when the new pid identity is observed.

2. The Rust test failure was caused by COW path resolution not mapping dirfd targets that already point into the COW upper layer back to the logical workdir path. I added that upper-to-workdir mapping and extended the COW chdir test to cover mkdirat through a directory fd.