feat(lab12): kata vs runc isolation + perf + escape PoC

[RanisKhaertdinov]

Goal

Install Kata Containers as a containerd runtime, run the same workload on runc and kata side-by-side to compare kernel isolation and performance
overhead, and demonstrate a real container-escape PoC that succeeds on runc but is blocked on kata.

Changes

• .github/workflows/lab12-kata.yml — this lab can't run locally (Kata needs a Linux host with /dev/kvm; this machine is a KVM-less macOS laptop). Instead of spinning up a paid
  cloud VM, the whole lab runs as a GitHub Actions workflow on a standard ubuntu-latest runner, which ships with a working /dev/kvm (free for this public repo — the same trick
  Android-emulator CI jobs use). The workflow installs containerd/nerdctl/Kata via the lab's own provided scripts, runs Task 1/2/Bonus end-to-end, and uploads every result as an
  artifact.
• submissions/lab12.md — full writeup: host/Kata versions, kernel-inside-container comparison, /dev + capability diffs, 5-run startup benchmark, I/O benchmark, and a three-way
  escape PoC comparison (runc succeeds / Kata --privileged fails to even start / Kata bind-mount-only still writes through) with an honest threat-model analysis of what Kata does
  and doesn't block.

Testing

• Confirmed KVM actually works on the runner before building anything on top of it: /dev/kvm present, kvm-ok → "KVM acceleration can be used"
• Kata installed (v3.32.0) and registered with containerd (v2.2.6, already present via Docker's containerd.io package) via the lab's install-kata-assets.sh /
  configure-containerd-kata.sh scripts
• Task 1: kernel inside a runc container is the host's own kernel (6.17.0-1020-azure); inside kata it's a completely different guest kernel (6.18.35) — confirms the VM
  boundary is real, not cosmetic
• Task 2: /dev and capability sets are nearly identical between runtimes (isolation shows up in the kernel, not in these surface properties) — 5-run startup benchmark shows
  5.75× overhead for Kata (0.312s vs 1.793s avg), matching Reading 12's "~5×" expectation almost exactly; I/O throughput is close between the two (25.5 vs 21.0 GB/s), confirming
  Kata's cost is mostly at startup, not steady-state
• Bonus: runc --privileged + bind mount overwrites the real host file (verified from a separate host-side cat); the identical command on Kata fails to even start the sandbox
  (Conflicting resource updates for host_major=8 host_minor=1 — Kata's privileged-mode device passthrough collides with the CI runner's own root disk already being mounted); a
  follow-up test with the bind mount only (no --privileged) shows the write does land on the host under Kata too — correctly identified as expected behavior (bind mounts are
  explicit grants on any runtime) rather than claimed as a "block," which shaped the submission's threat-model section

Two real bugs were hit and fixed while building the CI workflow (both explained inline in the workflow and in the submission): containerd couldn't find the Kata shim binary
because it wasn't on containerd's own PATH (fixed via symlinks into /usr/local/bin), and the --privileged disk-passthrough conflict above.

Artifacts & Screenshots

No screenshots — all evidence is real command output from the GitHub Actions run, quoted directly in submissions/lab12.md (kernel diffs, benchmark numbers, escape PoC output,
host-side verification). Full logs and downloadable artifacts are on the workflow run itself (Lab 12 Kata vs runc, run 29524188412) in this repo's Actions tab.

Checklist

• Title is clear
• No secrets
• Submission exists
• Task 1 — Kata installed; both runtimes run; kernel diff documented
• Task 2 — Isolation + 5-run startup + I/O benchmark with trade-off analysis
• Bonus — Escape PoC succeeds on runc; Kata's behavior investigated and honestly characterized (not a clean single-outcome "fails," see submission for the nuanced three-way
  result)