NVIDIA / NVIDIA/OpenShell

bug(vm-driver): packaged macOS ARM64 runtime lacks usable Landlock ABI

Open
#3,095 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

state:accepted
Dominant language
Rust
Stars
8.7k
Forks
1.3k
Avg merge
2d 11h
Merged PRs (30d)
253

Description

User Story

As an operator using the OpenShell VM driver on Apple Silicon,
I need landlock.compatibility: hard_requirement to be enforceable in the packaged guest,
so that VM-backed sandboxes can fail closed with mandatory filesystem isolation.

Problem Statement

OpenShell v0.0.116 successfully boots VM sandboxes on Apple Silicon, but the packaged guest kernel does not expose a usable Landlock ABI. A direct landlock_create_ruleset(..., LANDLOCK_CREATE_RULESET_VERSION) query returns ENOSYS. Sandbox creation with landlock.compatibility: hard_requirement fails with Landlock Filesystem Sandbox Unavailable, including when every listed filesystem-policy path is verified to exist.

The current rolling vm-runtime-darwin-aarch64.tar.zst is byte-for-byte identical to the artifact embedded in v0.0.116, so the rolling runtime reproduces the same behavior.

Impact / Why This Matters

Operators who require fail-closed filesystem containment cannot qualify or use the VM backend on Apple Silicon. The only OpenShell compatibility alternative is best_effort, which may continue without Landlock when the ABI is unavailable. Security-sensitive workloads must therefore remain on another backend or maintain a custom VM runtime. This blocks adoption of the stronger VM boundary for workloads that require mandatory filesystem enforcement.

Acceptance Criteria
  • The packaged macOS ARM64 VM guest returns Landlock ABI version 1 or higher from the version query.
  • A sandbox using landlock.compatibility: hard_requirement and known-existing paths reaches Ready.
  • A runtime smoke test demonstrates that a declared path is accessible and an undeclared path is denied.
  • The VM-runtime build fails unless the final kernel config has CONFIG_SECURITY=y, CONFIG_SECURITY_LANDLOCK=y, and CONFIG_LSM contains landlock.
  • Runtime provenance records the effective kernel version, libkrunfw commit, and final kernel-config hash.
Reproduction Steps
  1. Install OpenShell v0.0.116 on Apple Silicon and start a VM-driver gateway.

  2. Create a diagnostic sandbox and confirm the guest reports Linux 6.12.76 aarch64.

  3. Query the Landlock ABI in the guest:

    import ctypes, errno
    libc = ctypes.CDLL(None, use_errno=True)
    result = libc.syscall(444, None, 0, 1)
    error = ctypes.get_errno()
    print(result, error, errno.errorcode.get(error))
    

    Observed: -1 38 ENOSYS.

  4. Create a sandbox with landlock.compatibility: hard_requirement and only paths confirmed to exist in the guest.

  5. Observe provisioning fail with Landlock Filesystem Sandbox Unavailable.

Environment
  • OpenShell: 0.0.116
  • Host: Apple Silicon, macOS 26.3.1, arm64
  • Driver: openshell-driver-vm 0.0.116
  • Guest: Linux 6.12.76 aarch64
  • VM runtime SHA-256: 04349e6395c60e8cda059cc74e24105fdd23cec49ceac84966ce7377396e757d
  • VM runtime build source: 56088d0811f35d01e5af8f975335c9d0e30524be
  • VM runtime GitHub run: 33026157021
  • Pinned libkrunfw: 463f717bbdd916e1352a025b6fb2456e882b0b39
Logs
OCSF FINDING:CREATE [HIGH] "Landlock Filesystem Sandbox Unavailable" [type:landlock-unavailable confidence:high]
landlock_abi_result=-1 errno=38 errno_name=ENOSYS


Source inspection at the runtime build commit shows the pinned ARM64 libkrunfw base config has `# CONFIG_SECURITY is not set` and a `CONFIG_LSM` value without `landlock`. OpenShell's fragment requests `CONFIG_SECURITY_LANDLOCK=y` but does not enable `CONFIG_SECURITY` or add `landlock` to `CONFIG_LSM`. The build verification loop checks only `CONFIG_BRIDGE`, `CONFIG_NETFILTER`, and `CONFIG_NF_NAT`, so `olddefconfig` can discard the Landlock request without failing the build.

Related issue #2587 contains the same Landlock warning in VM logs but concerns an independent SSH relay disconnect.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at VM-runtime build source commit 56088d0811f35d01e5af8f975335c9d0e30524be, inspecting the pinned libkrunfw base config, kernel fragment, and build verification loop described in the report. Run the Apple Silicon diagnostic and hard_requirement smoke tests, including declared and undeclared path access. Done means ABI version 1 or higher, successful Ready provisioning, enforced access, required config validation, and provenance for the kernel, libkrunfw commit, and config hash.

Written by the indexing model from the issue text.

Assessment

Tech stack
linux, macos
Domain
build-system, infrastructure, operating-systems, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.