SuperPass: Fast-Tracking Blocking Threads to Mitigate Priority Inversion on Mobile Devices

Lei Li, Yu Liang, Riwei Pan et al. · Mohamed bin Zayed University of AI / City University of Hong Kong / National Taiwan University · 2026-07-20

🎯 核心问题
Android 上高优先级线程（如前台 App 的 UI 线程）被低优先级线程频繁阻塞，产生优先级反转。实测阻塞时长可达 210 ms，足以导致掉帧。传统实时系统中的优先级继承等方案在 Android 通用调度场景下要么无法消除长阻塞，要么引入过高开销。

🔧 关键方法
提出 SuperPass，一种轻量级内核调度机制。核心有两个组件：
① Scheduler fast track：当检测到低优先级线程正在阻塞延迟敏感线程时，立即授予该低优先级线程 CPU 时间（"快车道"），而非简单提升其优先级。这避免了优先级继承带来的级联效应。
② Lock-level detector：在锁层面追踪阻塞关系。论文的关键 insight 是：长阻塞主要源于低优先级线程累积的 CPU 等待时间而非其临界区执行时间；且虽然可能有大量并发读者，但只需追踪有限数量的阻塞线程即可在大多数情况下获得良好响应性。

📊 实验或论据
在 Google Pixel 8 上评估，以 UI 线程为案例。与默认调度器对比：99.9 分位阻塞时长降低 72.0%，阻塞次数减少 47.7%，janky frames 减少 29.2%，系统级 CPU 开销仅 0.74%。同时对比了 priority inheritance、real-time UI promotion 和 Proxy Execution 三种已有方案，SuperPass 均胜出。

⚠️ 局限
案例研究聚焦于 UI 线程这一种延迟敏感场景；Android 平台特定的调度语义是否能平滑迁移到其他通用 OS（如桌面 Linux）需要进一步验证。lock-level detector 仅追踪"有限数量"的阻塞线程，极端并发场景下的覆盖率未详细讨论。

💼 对系统人的启示
这是一篇非常实用的内核调度优化工作。对 Android 系统工程师来说，0.74% 的开销换来 72% 的尾延迟改善，性价比极高。"fast track"思路——不改优先级而是临时借 CPU——对其他场景（如容器调度、数据库锁竞争）也有借鉴意义。值得关注其是否会提交 Android Common Kernel 上游。

Isolation Failure From Shared Storage: Characterizing and Exploiting Page-Cache SCA Leakage Across Containers and VMs

Alon Abudraham, Xingyu Chen, Itamar Levi et al. · Bar-Ilan University / Boston University · 2026-07-20

🎯 核心问题
现代云平台依赖容器和 VM 做租户隔离，但宿主机的 page cache 在多种隔离方案下仍然是共享且可观测的。这构成了一条 OS 介导的微架构时序侧信道——其信号由处理器微架构、内存/存储层级和虚拟化机制共同塑造。问题是：非特权的时序测量能否跨越这些隔离边界探测 page cache 驻留状态？

🔧 关键方法
系统性评估了完整的云端隔离技术栈：Docker（直接共享内核）、gVisor（systrap 和 KVM 两种模式）、Kata Containers（QEMU 和 Cloud Hypervisor + 共享宿主文件系统；QEMU、Cloud Hypervisor 和 Firecracker + 块设备存储）、以及 QEMU/KVM 虚拟机（多种宿主缓存策略）。对每种配置测量非特权进程探测 page cache 命中/未命中的时序差异，覆盖 OverlayFS 层、virtio-fs 导出、loop-backed 块设备等 I/O 路径。

📊 实验或论据
核心结论：只要 I/O 路径暴露了共享的、宿主可缓存的 file-backed 对象，时序信号就持续存在。OverlayFS、virtio-fs、loop-backed 块设备均泄漏。但 Direct I/O 和专用块设备能大幅衰减或消除信号。虚拟化通过引入额外延迟和算法噪声重塑了泄漏形态，但并未移除对共享硬件和缓存状态的根本依赖。案例研究：从 MySQL 支撑的 WordPress 部署中恢复粗粒度活动。

⚠️ 局限
案例研究展示的是粗粒度活动恢复（WordPress 请求模式），而非密钥提取等高精度攻击。Direct I/O 已能有效缓解，但论文未量化切换到 Direct I/O 后的性能代价。此外，评估集中在 Linux 平台，Windows Hyper-V 等其他虚拟化方案未覆盖。

💼 对系统人的启示
对云基础设施工程师来说，这是一个清晰的安全架构指南：如果你用 virtio-fs 或 OverlayFS 做跨租户共享文件系统，page cache 侧信道不可避免。实际缓解手段明确——Direct I/O 或专用块设备。论文将 page-cache 攻击归入 OS 介导的微架构时序信道这一更广泛类别，有助于系统性地思考隔离设计。

TRIM: Reducing AI-Generated CodeSlop via Agent Trajectory Minimization

Alex Mathai, Shobini Iyer, Aleksandr Nogikh et al. · Google / Columbia University · 2026-07-20

🎯 核心问题
AI 编码 agent 在迭代搜索解决方案的过程中会累积大量"投机性编辑"、废弃假设和临时修改，最终产出的 patch 比人类实现更臃肿冗余。论文将这一现象正式定义为 CodeSlop——AI 生成代码中功能无关的残留编辑。当 agent 负责的代码库比例越来越大时，这种冗余以比人工清理更快的速度累积，导致代码库逐渐退化。

🔧 关键方法
提出 TRIM（Trajectory-guided Redundancy Identification and Minimization）算法。核心思路是间接策略：不直接对最终代码做冗余检测，而是回溯并最小化 agent 的搜索轨迹（trajectory）——识别轨迹中哪些步骤对最终通过测试的解是必要的，去除不必要步骤后重新生成精简 patch。这绕过了直接代码最小化的语义困难。

📊 实验或论据
跨多种 agentic scaffolds 评估，TRIM 将 CodeSlop 减少 17.9%-32.9%，性能回归可忽略。效率方面，验证成本约为 Delta Debugging 算法基线的一半。📄 具体的 benchmark 和 scaffold 类型在 abstract 中未详述，需读全文了解。

⚠️ 局限
主分类为 cs.SE，与 OS 的关联主要是交叉标注。abstract 未提及在系统级代码（如内核模块、驱动程序）上的评估，CodeSlop 在这类对正确性要求极高的场景下的表现和风险尚不清楚。此外，17.9%-32.9% 的缩减意味着仍有大量 CodeSlop 残留。

💼 对系统人的启示
如果你已经在用 AI agent 写内核补丁或系统工具，这篇值得关注——CodeSlop 在安全敏感的系统代码中尤其危险（多余代码 = 多余攻击面）。TRIM 的轨迹最小化思路可以作为 AI 辅助系统开发流程中的后处理步骤。但对纯 OS 研究者来说优先级不高。

机构观察：本周 cs.OS 一级分类仅 SuperPass 一篇（Lei Li / Chun Jason Xue 团队，长期活跃于嵌入式/移动系统调度领域）。Page-Cache SCA 来自以色列 Bar-Ilan 大学与 Boston University 的安全团队，TRIM 则来自 Google 研究院与哥伦比亚大学 Junfeng Yang 组（SOSP/OSDI 常客）。圈子虽小但覆盖面广：调度、安全、AI4SE 各占一席。

1. 移动端内核调度重回视野。SuperPass 显示 Android 上的优先级反转问题远比此前认知的严重（210 ms 级阻塞），而传统 RTOS 方案在通用 OS 上效果有限。随着移动设备上 AI 推理负载增加（大模型本地推理对延迟敏感），调度层面的精细优化需求可能进一步增长。

2. 容器/VM 隔离的"最后一公里"仍在 page cache。Page-Cache SCA 论文再次确认：只要 I/O 路径共享宿主文件缓存，隔离就不是完整的。在 confidential computing 和 TEE 热度持续走高的当下，存储层侧信道可能成为下一个重点攻防方向。

3. AI 生成代码的"系统卫生"问题浮出水面。TRIM 将 CodeSlop 正式命名并量化，这对系统软件尤为重要——内核代码中多余的代码路径意味着多余的攻击面和维护负担。随着 AI agent 在系统开发中渗透率提升，如何保持代码库的精简将成为工程管理的新课题。