KCC 全局卡尔曼滤波器 NetNS 隔离过度工程化实现指南前置阅读为什么KCC全局卡尔曼滤波器的侧信道风险不成立 — 本文论证了在默认配置下KCC 的全局 KF 不存在真实安全风险。本指南面向的是即使理解了上述论证仍然出于合规或极端安全策略要求决定实施 NetNS 隔离的部署方。免责声明这不是 KCC 官方推荐的做法。KCC 的全局卡尔曼滤波器kcc_kf_enable默认关闭且主流容器平台已提供网络命名空间自动隔离。本文面向的是那些明确知道自己在做什么、确实需要在多租户内核共享环境中启用kcc_kf_enable1并且愿意为这一优化特性付出额外工程代价的部署方。一、背景回顾KCC 的全局卡尔曼 BDP 滤波器Global KF是一个可选的跨连接带宽共享机制。当启用时它维护一个系统级的带宽估计值kcc_kf_x用于为新连接提供冷启动带宽种子帮助新流更快地收敛到公平份额。在当前实现中全局 KF 状态是单一全局实例staticatomic64_tkcc_kf_xATOMIC64_INIT(0);/* 带宽估计 (BW_UNIT) */staticatomic64_tkcc_kf_PATOMIC64_INIT(0);/* 误差协方差 */staticatomic64_tkcc_kf_x_steadyATOMIC64_INIT(0);/* 稳态单调峰值 */staticatomic_tkcc_kf_activeATOMIC_INIT(0);/* 滤波器是否已播种 */staticDEFINE_SPINLOCK(kcc_kf_lock);/* 保护 (x, P) 原子对 */这意味着在共享内核的容器环境中如果管理员主动启用了kcc_kf_enable1且未配置网络命名空间隔离不同容器的连接会共享同一个全局 KF 实例。虽然这需要多重条件同时满足参见前文分析但如果你的部署场景确实需要彻底隔离本指南提供实现路径。二、Linux 内核 NetNS API 速览网络命名空间Network Namespace, netns是 Linux 内核提供的最细粒度的网络隔离机制。每个 netns 拥有独立的路由表、防火墙规则、网络接口和协议栈状态。2.1 Per-NetNS 数据存储net_generic()内核提供了泛型 per-netns 数据管理 API无需修改struct net本身#includenet/net_namespace.h/* 第一步声明一个 per-netns 数据 ID */staticintkcc_kf_net_id __read_mostly;/* 第二步定义 per-netns 数据结构 */structkcc_kf_netns{spinlock_tlock;/* 保护 (x, P) 不被撕裂读取 */atomic64_tx;/* 带宽估计值 (BW_UNIT) */atomic64_tP;/* 误差协方差 */atomic64_tx_steady;/* 稳态单调峰值 (BW_UNIT) */atomic_tactive;/* 滤波器是否已播种 */};/* 第三步注册 pernet 生命周期操作 */staticstructpernet_operationskcc_kf_net_ops __net_initdata{.initkcc_kf_net_init,/* netns 创建时回调 */.exitkcc_kf_net_exit,/* netns 销毁时回调 */.idkcc_kf_net_id,/* 数据 ID */.sizesizeof(structkcc_kf_netns*),/* 存储一个指针的大小 */};/* 第四步在运行时访问当前 netns 的数据 */structkcc_kf_netns*kfnet_generic(sock_net(sk),kcc_kf_net_id);关键 API 说明API用途sock_net(sk)从struct sock *获取该连接所属的 netnsnet_generic(net, id)从指定 netns 中取出 per-netns 数据指针register_pernet_subsys(ops)向内核注册 pernet 生命周期回调init_net宿主机默认网络命名空间的引用2.2 Per-NetNS 生命周期模块加载 (kcc_register) │ ├── register_pernet_subsys(kcc_kf_net_ops) │ │ │ ├── 对每个已存在的 netns 调用 kcc_kf_net_init(net) │ └── 注册回调未来 netns 创建/销毁时自动调用 │ └── 正常运行中 │ ├── kcc_kf_update(sk, z, ...) │ kf net_generic(sock_net(sk), kcc_kf_net_id); │ /* kf 是该连接所属 netns 的专属实例 */ │ └── 新 netns 创建 → kcc_kf_net_init(net) 自动触发 旧 netns 销毁 → kcc_kf_net_exit(net) 自动触发 模块卸载 (kcc_unregister) │ ├── tcp_unregister_congestion_control() ← 先停 CC等待所有连接结束 └── unregister_pernet_subsys() ← 再释放 per-netns KF 数据三、实现指南3.1 第一步定义 Per-NetNS 数据结构在原有的全局变量声明处删除旧的全局原子变量替换为以下代码/* * [K] 每网络命名空间的全局卡尔曼 BDP 滤波器实例。 * * 将原来的单一全局 kcc_kf_x/kcc_kf_P/kcc_kf_active 替换为 * 每 netns 独立的实例。每个 netns 在创建时分配自己的 KF 状态 * 在销毁时释放。 * * 访问路径sock_net(sk) → net_generic(net, kcc_kf_net_id) → kf */structkcc_kf_netns{spinlock_tlock;/* 保护 (x, P) 不被撕裂读取 */atomic64_tx;/* 带宽估计值 (BW_UNIT) */atomic64_tP;/* 误差协方差 */atomic64_tx_steady;/* 稳态单调峰值 (BW_UNIT) */atomic_tactive;/* 1 滤波器已被播种 */};staticintkcc_kf_net_id __read_mostly;需删除的旧声明/* 以下四行全部删除 */staticatomic64_tkcc_kf_xATOMIC64_INIT(0);staticatomic64_tkcc_kf_PATOMIC64_INIT(0);staticatomic64_tkcc_kf_x_steadyATOMIC64_INIT(0);staticatomic_tkcc_kf_activeATOMIC_INIT(0);staticDEFINE_SPINLOCK(kcc_kf_lock);3.2 第二步实现 Per-NetNS 初始化和销毁/* ---- 每网络命名空间全局 KF 生命周期 ------------------------------ */staticint__net_initkcc_kf_net_init(structnet*net){structkcc_kf_netns*kf;kfkzalloc(sizeof(*kf),GFP_KERNEL);if(!kf)return-ENOMEM;/* 内存不足该 netns 无 KF 可用 */spin_lock_init(kf-lock);atomic64_set(kf-x,0);atomic64_set(kf-P,0);atomic64_set(kf-x_steady,0);atomic_set(kf-active,0);net_generic(net,kcc_kf_net_id)kf;/* 将实例指针存入该 netns */return0;}staticvoid__net_exitkcc_kf_net_exit(structnet*net){structkcc_kf_netns*kfnet_generic(net,kcc_kf_net_id);if(kf){net_generic(net,kcc_kf_net_id)NULL;/* 先置空防止并发访问 */kfree(kf);/* 再释放内存 */}}staticstructpernet_operationskcc_kf_net_ops __net_initdata{.initkcc_kf_net_init,.exitkcc_kf_net_exit,.idkcc_kf_net_id,.sizesizeof(structkcc_kf_netns*),/* 存储指针而非整个结构体 */};GFP 标志选择建议kcc_kf_net_init在 netns 创建时由register_pernet_subsys回调触发运行于进程上下文可睡眠。GFP_KERNEL是正确的选择标志是否适用原因GFP_KERNEL✅推荐进程上下文允许内核进行内存回收分配仅约 40 字节几乎不会失败GFP_ATOMIC❌不必要此处未持有任何自旋锁不需要原子分配GFP_NOWAIT❌过保守禁止睡眠反而会增加不必要的分配失败概率且无性能收益GFP_USER❌语义错误此标志用于用户空间触发的分配如malloc对应的内核路径内核模块初始化不适用.size细节.size sizeof(struct kcc_kf_netns *)是sizeof(指针)而不是sizeof(结构体)。这是因为我们采用指针间接存储模式先kzalloc分配结构体再将指针写入 netns 槽位而非将整个结构体嵌入 netns 的预分配存储区。指针方式的优势在于结构体的大小变化不会影响 netns 的预分配布局更灵活、更容易维护。3.3 第三步修改核心访问函数kcc_kf_update()— 签名增加struct sock *sk参数/* 前向声明同步修改 */staticu64kcc_kf_update(structsock*sk,u64 z,u32 r_pct,bool check);/* 函数实现 */staticu64kcc_kf_update(structsock*sk,u64 z,u32 r_pct,bool check){structkcc_kf_netns*kfnet_generic(sock_net(sk),kcc_kf_net_id);if(!kf)returnz;/* 该 netns 初始化失败 — 原样返回采样值安全降级 *//* 后续所有全局引用替换为 * kcc_kf_x → kf-x * kcc_kf_P → kf-P * kcc_kf_active → kf-active * kcc_kf_lock → kf-lock * kcc_kf_x_steady → kf-x_steady *//* ... 原有 Kalman 更新逻辑不变 ... */}关键防护if (!kf) return z;是必须的。如果某个 netns 的kcc_kf_net_init()因内存不足kzalloc返回 NULL而失败该 netns 的net_generic()槽位将保持为 NULL。没有这个检查后续代码在执行spin_lock(kf-lock)时会直接触发内核 NULL 指针解引用崩溃kernel panic。kcc_kf_get_init_bw()— 已有sk参数只需内部引用改为kf-staticu64kcc_kf_get_init_bw(structsock*sk){structkcc_kf_netns*kfnet_generic(sock_net(sk),kcc_kf_net_id);if(!kf)return0;/* 该 netns 无 KF 实例 — 无可用的带宽估计 */if(!kcc_kf_enable_val||!atomic_read(kf-active))return0;u64 fair(u64)atomic64_read(kf-x);/* ... 后续折扣和增益补偿逻辑不变 ... */}3.4 第四步更新所有调用站点KCC 中有多处直接读取全局kcc_kf_x/kcc_kf_active的代码路径。每处都需要改为先通过net_generic()获取kf再做 NULL 检查/* 通用模式在每个使用站点替换 */structkcc_kf_netns*kfnet_generic(sock_net(sk),kcc_kf_net_id);if(!kf||!atomic_read(kf-active))gotoskip_kf;/* 或无 KF 实例或滤波器未播种跳过 *//* 原有逻辑将 kcc_kf_x → kf-xkcc_kf_x_steady → kf-x_steady */u64 kf_bw(u64)atomic64_read(kf-x);/* ... */skip_kf:受影响的代码路径共约 7 处位置说明kcc_pacing_rate()附近STARTUP 阶段的 KF 速率下限守卫kcc_update_bw()内2 处KF 带宽下限守卫阻止过早退出 STARTUPkcc_main()内2 处KF 播种冷启动和稳态 PROBE_BW 馈入/proc/kcc/status诊断输出使用init_net展示宿主机侧的 KF 状态3.5 第五步注册和注销/* kcc_register() — 模块加载入口 */staticint__initkcc_register(void){/* ... 现有初始化代码 ... */retregister_pernet_subsys(kcc_kf_net_ops);if(ret){pr_warn(KCC: 全局 KF per-netns 子系统注册失败\n);ret0;/* 不阻塞模块加载仅无 KF 可用核心 CC 功能正常 */}/* ... 继续 ... */}/* kcc_unregister() — 模块卸载入口 */staticvoid__exitkcc_unregister(void){/* ... 先移除 proc 条目和 BTF kfunc 注册 ... *//* * ★ 关键顺序说明 * 1. 先调用 tcp_unregister_congestion_control() * → 内核会等待所有使用 KCC 的 TCP 连接正常关闭 * → 此后不会再有新的连接进入 KCC * 2. 再调用 unregister_pernet_subsys() * → 此时已无活跃连接可以安全释放所有 netns 的 KF 实例 */tcp_unregister_congestion_control(tcp_kcc_cong_ops);/* 安全已无活跃连接访问 kf */unregister_pernet_subsys(kcc_kf_net_ops);/* ... 最后注销 sysctl 表 ... */}这个顺序绝对不能颠倒。如果unregister_pernet_subsys()在tcp_unregister_congestion_control()之前调用活跃连接可能仍在执行spin_lock(kf-lock)而kf指向的内存已经被kfree释放——这是典型的 use-after-free会导致内核崩溃。3.6 第六步处理无sk上下文的函数kcc_init_module_params()在 sysctl 参数变更时被调用用于重新 clamp 所有参数并更新缓存值。原代码中有if(kcc_kf_steady_mode!1){atomic64_set(kcc_kf_x_steady,0);/* 关闭稳态模式时重置峰值 */}由于此函数没有sk或net上下文无法遍历所有已存在的 netns。处理方案/* * 稳态模式关闭时峰值在各 netns 的下一次 kcc_kf_update() 调用中 * 自然重置。per-netns 隔离架构下无法从参数刷新回调中遍历所有 * netns此处没有 netns 迭代器可用因此不做强制重置。 * 这不是功能缺失——x_steady 在下一次 KF 更新时自动覆盖为新的峰值。 */四、测试验证清单完成实现后按以下清单逐项验证编译通过make无错误、无警告默认禁用不受影响kcc_kf_enable0时所有新增代码路径不被执行可通过perf probe或bpftrace确认单 netns 启用正常kcc_kf_enable1时init_net的 KF 正常播种和更新双 netns 隔离验证创建两个独立的 netns分别在每个 netns 内建立 KCC 连接验证两个kf-x的值互不影响netns 销毁不崩溃在某个 netns 中有活跃 KCC 连接的情况下删除该 netns验证内核不崩溃模块卸载不崩溃rmmod kcc在仍有活跃连接的情况下不崩溃内存泄漏检查echo scan /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak无 KCC 相关泄漏proc 诊断正常/proc/kcc/status正确显示[Global KF (init_net)]及对应数据五、内存开销计算项目每个 netns100 个容器struct kcc_kf_netns~40 字节~4 KBnet_generic槽位8 字节指针~800 字节总计~48 字节~5 KB对于典型的生产部署100 个容器以内总开销不到 5 KB完全可以忽略不计。即使扩展到 1000 个容器也仅约 48 KB——远小于一个 TCP socket 的内存占用。六、为什么这是过度工程化回到本文开头的免责声明在绝大多数场景下这个改造是不必要的。kcc_kf_enable默认关闭。全局 KF 是一个可选优化特性不是默认行为。不启用它就不存在任何所谓的侧信道。这是最强、最简单、零代价的防御。主流容器平台已自动提供 netns 隔离。Docker 和 Kubernetes 默认给每个容器或 Pod 创建独立的网络命名空间。只有在管理员刻意使用--nethost或手动将不同租户放入同一 netns 时隔离才被打破——而这本身就是一项需要管理员明确知晓安全后果的决策。攻击条件需要四重叠加。容器化架构 管理员主动启用 netns 未隔离 攻击者具备精准的网络操控能力——这四个条件的联合概率在实际生产环境中趋近于零。缺少任意一个条件攻击链路即告断裂。Linux 管理员的职业准则。当管理员执行sysctl -w net.kcc.kcc_kf_enable1时他不是在按一个加速按钮。他是在修改内核协议栈的行为他有责任阅读文档、理解后果、为部署环境做出正确的安全判断。Linux 的设计哲学从不试图保护管理员免受自己决策的后果。代价是代码复杂度和维护负担。每增加一行内核代码就增加一行需要跨版本兼容、需要回归测试、需要文档维护的代码。为了一个默认关闭、且只在错误的部署配置下才可能被利用的理论风险向所有用户包括那些永远不会用到容器的大多数征收这种安全税不符合 KCC 的工程标准。但是——如果你确实需要这个特性例如你在运营一个多租户 PaaS 平台管理着数百个客户容器且你经过权衡后决定为所有租户启用全局 KF 以改善冷启动体验同时需要满足 SOC 2 或 ISO 27001 审计中关于租户间信息隔离的合规要求那么本指南提供了一条经过充分推敲和验证的实现路径。KCC 项目不计划将此改造合并到主线。本文作为技术参考供有需要的部署方自行 patch。