Skip to content

nvx-rs: GPT images, the RAM upper and protected paths in nvx-rs sandbox #818

Closed

Description

Parent: #816. Needs: #817, whose init boots a GPT distro and the tmpfs upper. Builds on #813's GPT bindings. Delivers, with #817 and #591's docs: #558.

Goal. nvx-rs sandbox run, provision and start accept every format and upper that the shared plan supports, and refuse a share that reaches the sandbox's own files.

Today (dev c5a0dd7):

Scope:

  1. Formats and uppers: a GPT distro named by its disk GUID, and the tmpfs upper, with exactly one nvx_overlay_upper=ramfs token and no scratch block or token. They are planned through the typed plan for sandbox run, provision and start. The option forms are settled in the PR; today's EROFS forms keep their meaning.
  2. Bindings: provision records a GPT binding (sandbox: bind GPT disks, plan adapter launches, and stage registered images #813) as it records an EROFS one, and start checks it by metadata only. A tmpfs sandbox records and claims no scratch.
  3. Protected paths: a share is refused if its host path equals, contains or lies inside the sandbox's state directory, scratch, layers or bundle. Paths are compared by canonical path and by identity, at provision and again at start; sandbox run, which has no state directory, checks the rest.
  4. Records: the sandbox's records name its format and upper.

Not in scope: guest root assembly (#817); nvx-rs run's shares (#802); protected roots chosen by the library; image management.

Acceptance:

  • sandbox run, provision and start each boot all four format and upper combinations on KVM, MSHV and WHP. Tests assert the selected filesystem and upper, the expected identities, the block size, and no scratch in RAM mode.
  • A GPT image that changed after provision fails start without reading content, and a wrong disk GUID fails the assembly. Conflicting upper settings are refused.
  • Protected-path tests cover a single share, symbolic link, junction and bind-mount aliases, and a state directory created during provision.
  • Unchanged cases keep their goldens. Intended changes are limited to the format token, the protected paths and the records.

Carries over: #622's scope 7 (A4 PR 7), apart from the binding that provision already records, and the CLI's part of #622's first acceptance item.

Activity

  1. esaurez commented on Nov 1, 2026

    @esaurez
    ContributorAuthor

    Rescoped by the nvx-rs slimming workstream (#1076). nvx-rs sandbox gets GPT and EROFS images, a scratch or a RAM upper with its cap (50% of memory by default), and protected paths, checked by canonical path at provision and again at start, on nvx-cli's own store and the new launch APIs. Delivered by #1110 and #1111; image staging and the path rules then move into nvx-cli in #1124 and #1125.

  2. ppenna commented on Nov 13, 2026

    @ppenna
    Contributor

    Completed on feature/nvx-refactor, as rescoped above for #1076. The groups that deliver it have merged and closed as completed:

    The options are --layer-format {erofs,gpt}, --upper {scratch,ram} and --ram-upper-percent. As #1110 scoped them, the protected paths are compared after resolution, which follows symbolic links and junctions but not hard links or bind mounts; there is no alias matrix. #1118's twelve cold cells, EROFS and GPT over a scratch or a RAM upper on KVM, MSHV and WHP, run in the public sandbox scenarios.

    The push CI run at 367f7fe4d0, which contains all of them, passed, including those scenarios: https://github.com/microsoft/nvx/actions/runs/43363710885. dev receives it when feature/nvx-refactor lands there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions