Hardening gVisor sandbox configuration against CPU side-channel risks and binary mismatches #2136

Moving some internal security review bugs to github.

Summary

Untrusted workloads executing within the Substrate environment rely on the gVisor sandbox (runsc) for guest isolation. To prevent cross-tenant and host-level leakage and maintain sandbox integrity across upgrades, the sandbox runtime configuration should be hardened against CPU side-channel attacks and auxiliary binary version divergence.

Technical Details

1. CPU Core-Sharing Side Channels (SMT):
   Processors utilizing Simultaneous Multithreading (SMT / Hyper-Threading) are susceptible to CPU core-sharing side-channel attacks (e.g., L1TF, MDS) when untrusted code co-locates on sibling logical cores. runsc supports the enable-core-tags flag to isolate guest execution using core scheduling tags. On hardware architectures with SMT enabled, enabling core tagging prevents information leakage across sibling threads.

2. Sandbox Component Version Alignment:
   runsc resolves auxiliary sidecar binaries located in adjacent directories. If underlying host files or sidecar binaries diverge across upgrades, protocol mismatches or partial patching can weaken sandbox boundaries. Setting --sidecar-release-enforcement-policy=ALWAYS ensures that all spawned auxiliary helper binaries match the exact release build of the main runsc binary.

Code Context

• cmd/ateom-gvisor/runsc.go: Spawns and configures runsc execution flags for container creation, startup, checkpoint, and restore.

Proposed Mitigations

1. Evaluate and conditionally set enable-core-tags=true in cmd/ateom-gvisor/runsc.go when running on platforms with hyperthreading / SMT enabled.
2. Configure --sidecar-release-enforcement-policy=ALWAYS for runsc invocations to guarantee atomic version alignment across runtime binaries.