不成立。cgroup v2 仅提供内存资源配额与统计，无法阻断 Rowhammer、cache timing 等硬件级侧信道攻击；其 memory.min/high/max 控制用量而非缓存或页表隔离。
cgroup v2 与内存侧信道隔离的关系是否成立？
不成立。cgroup v2 本身不提供“内存侧信道隔离”能力，它只负责资源配额与统计，无法阻断如 Rowhammer、cache timing、TLB flush 等硬件级侧信道攻击路径。所谓“利用 cgroup v2 实现侧信道隔离”，是常见误解——v2 的 memory.min、memory.high 或 memory.max 控制的是内存用量上限与压力反馈，不是缓存行、页表项或 DRAM bank 的访问隔离。真正影响侧信道风险的是 CPU topology（如 NUMA node 绑定）、cache partitioning（如 Intel CAT）、以及内核的 vm.pagecache 行为，这些都不在 cgroup v2 职责范围内。
为什么生产环境仍需启用 cgroup v2？
因为它是现代容器运行时（runc ≥1.1.0、containerd ≥1.7）的强制基础，且相比 v1 具备三项关键优势：
-
unified层级结构避免子系统挂载冲突，使memory和cpu策略可原子生效 -
memory.pressure提供实时内存压力信号，配合用户态守护进程可触发主动限流（如暂停非关键容器） -
memory.swap.max=0可彻底禁用 swap，消除因页面换入换出引入的时序扰动（这对侧信道缓解有间接帮助）
启用方式（宿主机需支持并已启用 v2）：
echo"1"> /proc/sys/fs/cgroup/unified_hierarchy # 验证：ls /sys/fs/cgroup/ 下无 cpu、memory 等独立目录，只有 unified 目录结构
真正能缓解内存侧信道的实际配置组合
若你面临多租户容器共置（如金融风控模型与客户查询服务混跑）且需降低跨容器内存访问时序泄露风险，应组合以下措施：
- 强制容器绑定到独占 CPU core + 关闭超线程：
--cpuset-cpus="2" --ulimit nofile=65536:65536 --security-opt=no-new-privileges - 禁用透明大页（THP）：
echo"never"> /sys/kernel/mm/transparent_hugepage/enabled（需在宿主机全局设置） - 使用
memory.low为高优先级容器保底内存，避免其被低优先级容器挤出 page cache 导致频繁缺页重填（从而放大时序差异） - 对敏感容器启用
seccomp过滤perf_event_open、process_vm_readv等可用于侧信道探测的系统调用
示例：为风控容器设置保底与压力阈值
docker run -d \ --memory="2g" \ --memory-reservation="1.5g" \ --kernel-memory="1.8g" \ --security-opt seccomp=/path/to/restrictive.json \ nginx
其中 --memory-reservation 对应 cgroup v2 的 memory.low，--memory 对应 memory.max，--kernel-memory 实际映射为 memory.kmem.max（需内核开启 CONFIG_MEMCG_KMEM）。
容易被忽略的兼容性陷阱
很多团队在升级 cgroup v2 后发现监控失效或 OOM 行为异常，根本原因在于：
- Docker daemon 默认仍使用 v1 接口桥接，需显式配置
"features": {"cgroupv2": true}在/etc/docker/daemon.json中 - Kubernetes 1.25+ 才默认启用 cgroup v2，旧版本即使宿主机启用了 v2，kubelet 仍会 fallback 到 v1
-
docker stats输出的 memory usage 值在 v2 下反映的是memory.current，而非 v1 的hierarchical_memory_limit，工具链未适配会导致误判 - NVIDIA Container Toolkit 1.13.0 之前版本不支持 cgroup v2 的 GPU 内存控制器，混合部署 GPU 容器时必须升级
最隐蔽的一点：memory.pressure 是个瞬时快照文件，不可轮询读取——必须用 epoll 监听其 inotify 事件，否则会漏掉短时高压窗口，而这恰恰是侧信道探测常利用的资源争抢窗口。
