feat: switch the microVM guest kernel to the arcboxlabs/kernel microvm flavor (CORE-79)

[AprilNEA]

What

Repoints the vmlinux binary (the Firecracker sandbox guest kernel, install_dir = "kernel") from the stock Firecracker CI artifact (s3://spec.ccfc.min/firecracker-ci/v1.14/aarch64/vmlinux-6.1.155) to the dedicated minimal sandbox kernel built by arcboxlabs/kernel#18: microvm-kernel-arm64 from the kernel repo's GitHub release.

• Bundle shape unchanged (name = "vmlinux", install_dir = "kernel") → zero changes to the manifest schema, download/materialization code, or arcbox's kernel path.
• New immutable CDN version key bin/vmlinux/0.0.23-microvm/{arch}/vmlinux → rollback = revert this pin (old objects stay on B2).
• Firecracker restore never re-reads the kernel file, so existing template snapshots keep restoring unchanged.
• x86_64 stays on the FC CI kernel until an x86 microvm config lands (FC x86_64 boots an ELF vmlinux and needs VIRTIO_MMIO_CMDLINE_DEVICES + kvmclock).

⚠️ Merge order — do not merge yet

The pinned URL points at kernel release v0.0.23, which does not exist yet:

1. Merge feat: add microvm kernel flavor for Firecracker sandboxes (CORE-79) kernel#18, tag the kernel release.
2. Confirm/update the tag in this PR's URL + version to the actual tag, verify the asset downloads, then merge.
3. Merging to master fires sync-binaries.yml (B2 upload; sha256 is computed at sync time — cross-check against the release's microvm-kernel-arm64.sha256). The next boot-assets release (tag or kernel-release dispatch) embeds the sha into manifest.json.
4. arcbox then bumps assets.lock ([boot] version + manifest_sha256) and rebuilds the daemon — out of scope here; the sandbox boot_args cleanup (quiet loglevel=1, drop pci=off) rides that change.

[linear-code]

CORE-79

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[greptile-apps]

Greptile Summary

The PR switches the arm64 Firecracker guest kernel from the stock Firecracker artifact to the arcboxlabs/kernel microvm flavor while retaining the existing x86_64 source.

• Changes the shared vmlinux deployment pin to 0.0.23-microvm.
• Points the arm64 source at the planned v0.0.23 GitHub release asset.
• Documents architecture differences and rollback behavior.

Confidence Score: 5/5

The code change appears safe to merge after the explicitly documented kernel release is published and its asset URL is verified.

The configuration preserves the expected bundle shape and architecture-specific sources, and no unacknowledged blocking or independently actionable defect remains.

Important Files Changed

Filename	Overview
upstream.toml	Updates the arm64 guest-kernel source and shared deployment version while intentionally preserving the stock x86_64 kernel source; the unavailable release prerequisite is explicitly documented.

_{Reviews (1): Last reviewed commit: "feat(kernel): source the microVM guest k..." | Re-trigger Greptile}

[pullfrog]

Important

The pin is correct in shape but not yet resolvable: arcboxlabs/kernel is at v0.0.22, so v0.0.23/microvm-kernel-arm64 404s and Assemble (arm64) is red on this SHA. That matches the PR's own merge-order note — flagging it so the blocker is recorded, plus two things worth settling before the tag is cut.

Reviewed changes — full read of the single-file diff, cross-checked against how upstream.toml is consumed by sync-binaries, the release pipeline, and client-side download verification.

• vmlinux arm64 source repointed — from the stock Firecracker CI kernel (vmlinux-6.1.155) to microvm-kernel-arm64 off an arcboxlabs/kernel release; x86_64 stays on the FC CI kernel.
• Version bumped 6.1.155 → 0.0.23-microvm — this doubles as the immutable CDN key bin/vmlinux/{version}/{arch}/vmlinux, so it also re-keys the (unchanged) x86_64 object.
• Explanatory comment block added — records the microvm flavor's scope and why x86_64 is deferred.

Bundle shape is unchanged (name, install_dir), so no manifest-schema, download-code, or guest-path impact, and repository_upstream_config_is_valid still holds. I also checked the "no netfilter/PCI/ACPI/EFI" trade-off and found no regression reachable from this repo: dockerd/containerd/iptables run on the outer ArcBox kernel (the kernel-{arch} asset pulled in release.yml), not inside the Firecracker sandbox that boots this vmlinux.

⚠️ Nothing in this repo boots the kernel this PR pins

The change swaps a battle-tested general-purpose kernel for a bespoke minimal one, and no check in this repository will boot it. live-e2e.yml QEMU-boots only the outer kernel + rootfs and only on x86_64, and its checksum-validation leg defaults to BOOT_ASSETS_LIVE_ARCH=x86_64, so it won't even fetch the new arm64 object. The first evidence that a sandbox actually boots arrives downstream in arcbox after assets.lock moves — well past the point where a bad pin is cheap to undo.

Technical details

# No pre-merge validation path for the new sandbox kernel

## Affected sites
- `.github/workflows/live-e2e.yml:74,80-81` — the QEMU boot leg is gated to `x86_64`, so
  it exercises the outer kernel only; the microVM `vmlinux` is never booted on any arch.
- `.github/workflows/live-e2e.yml:70` — `BOOT_ASSETS_LIVE_ARCH` defaults to `x86_64`, so
  the `prepare_binaries` leg does not even checksum-validate the new arm64 object.
- `.github/workflows/sync-binaries.yml:62-63` — the "Verify CDN" step greps only the
  *first* `name`/`version` pair in `upstream.toml` (currently `dockerd`), so a missing or
  wrong `bin/vmlinux/0.0.23-microvm/arm64/vmlinux` object cannot be caught there.

## Required outcome
- Before this pin merges, someone has observed the pinned artifact actually boot a
  Firecracker microVM to PID 1 on arm64 — not just download successfully.
- After the sync lands, positive confirmation that the object is retrievable and matches
  the manifest sha256, rather than inferring it from a green `sync` job.

## Suggested approach (optional)
- Manual pre-merge check: download the release asset and boot it under Firecracker with
  the sandbox's real `boot_args`, confirming the kernel reaches init.
- Post-sync check: `workflow_dispatch` `live-e2e.yml` with `arch: arm64` and
  `boot_linux: false` — that runs `prepare_binaries` against the published CDN, which
  exercises `download_and_verify` for the vmlinux entry end to end.

## Open questions for the human
- Is a CI-side Firecracker smoke boot of the sandbox kernel in scope for this repo, or is
  that deliberately arcbox's responsibility? If the latter, this is a note, not a blocker.

ℹ️ Nitpicks

• The shared version field means manifest.json will advertise 0.0.23-microvm for the x86_64 vmlinux too, even though that target still ships FC CI 6.1.155. The TOML comment explains it, but downstream manifest consumers only see the version string. Inherent to one version per binary in the schema, so probably just worth knowing rather than fixing here.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[AprilNEA]

Unblocked — kernel v0.0.23 is released, this PR's pin now resolves.

microvm-kernel-arm64 published at the pinned URL (HTTP 200), sha256 b61bd2f4c33d82bad1105074ed0ba5c07f78ab4c5a97f39ce68e0971fa15b1c8. No sha field is needed here — the bundle manifest computes checksums at package time.

Measured size effect: the bundle gets smaller. The microVM kernel it replaces is the stock Firecracker CI image:

	before (FC CI 6.1.155)	after (arcbox microvm)
microVM kernel	17,111,552 B	8,857,608 B

−8.25 MB, −48%, despite CONFIG_MODULES=n (everything built in) — the cut driver and subsystem surface (PCI/ACPI/EFI, SCSI, full netfilter+conntrack, NFS/XFS/squashfs, AUDIT, NUMA, hibernation, VT/INPUT/HID/USB) more than pays for de-modularization. This is a replacement, not an addition: name="vmlinux", install_dir="kernel" and the bundle shape are unchanged, and boot assets are CDN-downloaded at first daemon start, so the macOS installer is unaffected either way.

x86_64 deliberately stays on the FC CI kernel until an x86 microvm config lands. Ready for review/merge; the arcbox-side assets.lock bump follows the boot-assets release.