Fixinf SPDK

docs/TODO.md

@@ -147,3 +147,27 @@ this item builds the rollout machinery around it.
   especially mid-rollout (N versions + reboot bursts).
 - Note: kiosk *content* changes are server-side (the website) and need no fleet
   update — only OS/UKI/rootfs changes require a reboot.
+
+## [ ] 7. Harden / evaluate the NVMe-oF target (serving-node resilience)
+
+There is **no production-grade memory-safe NVMe-oF target** — the Rust NVMe work
+is all driver/initiator-side (vroom, RedLeaf, Rust-for-Linux); the only
+production targets are C (Linux kernel `nvmet`, SPDK). So this is **serving-node
+hardening, not a language swap**. dm-verity already removes the target from the
+clients' integrity TCB (verify-on-read rejects tampered blocks), so the risk is
+RCE/DoS on the node that holds the fleet's disk, not client integrity. The
+export is read-only + single-namespace = inherently small attack surface.
+
+- **Evaluate kernel `nvmet` vs SPDK** for the target: kernel `nvmet` keeps the
+  data path in the hardened/fuzzed kernel with a tiny userspace footprint
+  (arguably a better attack-surface story); SPDK is a userspace C daemon
+  (current choice, needs hugepages + caps). Decide per environment.
+- **Confine the target** (whichever): unprivileged, drop caps, seccomp +
+  SELinux/AppArmor profile, read-only container, minimal mounts; minimal
+  immutable serving image, digest-pinned.
+- **Network-isolate :4420** so only the boot VLAN reaches the target (compose
+  with 802.1X/MACsec segmentation in prod).
+- **Replicas** behind distinct discovery entries (availability is the real risk
+  — it's the fleet's disk). Ties into #6 (rolling updates) availability.
+- Revisit a memory-safe target only if/when an off-the-shelf one matures
+  (e.g. a future Rust-for-Linux `nvmet`).