论文：Keystone with Linux PREEMPT_RT: Real-Time Enclaves on RISC-V?关键词：RISC-V、Keystone、TEE、PREEMPT_RT、实时 Linux、混合关键系统、调度延迟TEE 能保护机密数据，但它会不会破坏实时任务的时间确定性？更具体一点：Keystone 是 RISC-V 上一个开源 TEE 框架，Linux PREEMPT_RT 是让 Linux 更“实时”的补丁集合。那么，把 Keystone 跑在 PREEMPT_RT Linux 上，能不能既获得安全隔离，又获得可预测的实时响应？如果实时任务跑在普通 Linux 侧，Keystone enclave 只是后台运行，那么影响不明显；但如果实时任务本身要放进 enclave，尤其多个 enclave 并发启动，Keystone 会引入明显且不稳定的启动延迟。论文摘要也指出，Keystone 的 Secure Monitor 和 enclave 不会显著干扰高优先级非安全进程，但多个 enclave 并发执行时会带来 substantial latencies，限制其在需要“机密性 + 可预测时序”的场景中的适用性。一、先把问题讲清楚：安全和实时为什么会打架？
TEE，Trusted Execution Environment，可以理解为处理器提供的“安全房间”。应用把敏感代码和数据放进 enclave，外面的操作系统即使权限很高，也不能随便偷看或篡改。比如电网监控、机器人控制、车载系统、工业控制，它们不只要求数据安全，还要求任务响应时间稳定。如果一个任务本来应该 100 微秒后被唤醒，结果因为系统某处不可抢占、锁竞争、上下文切换等原因拖到了几毫秒甚至几百毫秒，那实时性就被破坏了。论文指出，TEE 的安全机制经常会带来额外的非确定性延迟，例如 timer、interrupt、enclave exit、上下文切换等，而这些问题在传统 TEE 研究里经常被认为是“可用性问题”或“不在范围内”。所以这篇论文不是在问“Keystone 安不安全”，而是在问：Keystone 在 RISC-V 上安全隔离时，会不会影响 Linux PREEMPT_RT 的实时调度表现？
二、背景知识：Keystone 和 PREEMPT_RT 分别是什么？
1. Keystone：RISC-V 上的开源 TEE
Keystone 是一个面向 RISC-V 的开源 TEE 框架。它的特点是尽量只使用标准 RISC-V 特性，不依赖定制安全扩展，因此更容易在真实 RISC-V 硬件上部署。论文介绍，Keystone 主要依赖 RISC-V 的特权级和 PMP，Physical Memory Protection，来隔离 enclave 内存。2. PREEMPT_RT：让 Linux 更适合实时任务
普通 Linux 不是硬实时操作系统。Linux 内核里有些路径不能随时被抢占，因此高优先级任务可能会被延迟唤醒。PREEMPT_RT 补丁的目标是减少 Linux 内核中不可抢占的区域，让高优先级任务更容易及时获得 CPU。论文提到，PREEMPT_RT 已经在 6.12 版本开始合入 Linux mainline，这说明它已经相当成熟。PREEMPT_RT 让 Linux 更实时，不等于让 Linux 变成严格硬实时 RTOS。论文也明确指出，由于 Linux 内核规模很大，即使有 PREEMPT_RT，也很难完全证明执行时间有严格上界，因此它更适合软实时或部分 firm real-time 场景。三、图 1：Keystone 的软件特权层级
论文第 3 页的Figure 1展示了 Keystone-enabled 平台的软件特权层级。M-mode，Machine mode：最高权限，一般跑 OpenSBI 和 Keystone Secure Monitor；S-mode，Supervisor mode：操作系统内核运行的位置，比如 Linux；U-mode，User mode：普通用户程序运行的位置。Keystone 的特殊之处在于，系统里同时存在“普通世界”和“安全 enclave 世界”：M-mode: OpenSBI + Keystone Secure MonitorS-mode: Host Linux kernelM-mode: Keystone Secure Monitor论文强调，Keystone 的 Secure Monitor 是核心组件，它是 OpenSBI 的扩展，运行在 M-mode，负责 PMP 配置、enclave 上下文切换、完整性检查和远程证明。Host OS 不需要被 enclave 信任，因为真正决定 enclave 隔离边界的是 Secure Monitor 和硬件 PMP。Linux 是“普通管理员”，Secure Monitor 是“最高级别的门禁系统”。Linux 可以调度程序，但 enclave 的内存隔离最终由 M-mode 的 Secure Monitor 配置 PMP 来保证。
四、图 2：Enclave 是怎么启动的？
论文第 3 页的Figure 2展示了 enclave 创建流程。这个图非常关键，因为本文后面测的很多延迟，实际上都和 enclave 创建有关。Host OS 加载 enclave binary；Secure Monitor 用 PMP 锁住内存区域；Secure Monitor 验证 enclave 没有被篡改；跳转到 enclave 入口，secure app 开始执行。论文指出，enclave 创建时间和 enclave binary 及 runtime 的大小相关，之前工作已经观察到大小和启动时间之间大致呈线性关系。如果一个实时任务必须“先创建 enclave，再开始执行”，那么它的响应时间就不仅仅取决于 Linux 调度，还取决于 Keystone enclave 创建流程。五、本文研究的两个场景
场景一：Mixed Context，混合上下文
实时任务跑在普通 Linux 侧，enclave 作为后台安全任务运行。后台运行 Keystone enclave，会不会影响普通 Linux 高优先级实时任务？
场景二：Real-Time Enclave，实时任务本身跑进 enclave
还是智能电网例子，如果加密报告不是“统计用途”，而是要参与本地电网调度决策，那么安全任务本身也有实时要求。如果实时任务必须在 enclave 中执行，Keystone enclave 的创建和启动延迟是否足够稳定？
论文用 cyclictest 测调度延迟，用 stress-ng 和 iperf3 制造 CPU、内存、磁盘、网络等压力，并在 HiFive Unmatched Rev. B RISC-V 开发板上实验。论文还说明，该板使用 SiFive Freedom U740 SoC，Linux 使用 4 个 U7 core，并有 8 个 PMP region。六、实验工具：cyclictest 到底在测什么？
论文使用cyclictest测调度延迟。它的基本思路是：论文中 cyclictest 使用默认的SCHED_FIFO调度类，并把任务优先级设置为 99。对于 real-time enclave 场景，作者还修改了 cyclictest，让它在每次迭代中请求创建 enclave，并在 enclave 内部记录真正开始执行的时间。cyclictest 测的是“高优先级任务被叫醒得有多准时”。修改版 cyclictest 测的是“高优先级 enclave 任务从请求到真正跑起来花多久”。
七、图 3：PREEMPT_RT 在 RISC-V 上确实有效
论文第 5 页的Figure 3比较了没有 Keystone 时，普通 Linux kernel 和 PREEMPT_RT kernel 的调度延迟。Figure 3 中，stock kernel 的延迟分布明显更散，并且右侧有长尾；PREEMPT_RT 的分布更集中，平均延迟更低，说明高优先级任务启动更可预测。论文也指出，这个结果符合已有 RT Linux 研究。在作者的 RISC-V 板子上，PREEMPT_RT 的确让 Linux 调度更稳定。
八、图 4 和图 5：后台 Keystone enclave 会不会干扰实时 Linux 任务？
接下来进入第一个核心场景：mixed context。作者在每个 core 上运行 Keystone enclave，同时继续用 cyclictest 测高优先级 Linux 任务的调度延迟。论文第 5 页的Figure 4比较了“有 Keystone 后台 enclave 时”的 stock kernel 和 PREEMPT_RT kernel。结果和 Figure 3 很像：PREEMPT_RT 仍然表现更好，延迟更低、更集中。更关键的是Figure 5。它只看 PREEMPT_RT kernel，对比：有 Keystone enclave 在后台运行。图中两组分布几乎重叠。论文据此认为，引入 Keystone enclave 并没有显著改变系统中高优先级 Linux 进程的调度延迟。如果实时任务仍然跑在 Linux 侧，而 enclave 只是作为普通优先级后台安全任务运行，那么 Keystone + PREEMPT_RT 是比较可行的。
换句话说，Keystone 没有明显“拖慢”普通实时 Linux 任务。九、图 6：单个 enclave 创建本身很稳定，但很慢
第二个场景更复杂：实时任务自己跑进 enclave。总延迟 = Linux 调度延迟 + Keystone enclave 创建延迟论文第 6 页的Figure 6单独测了 enclave 创建持续时间，不加 stressor，只用一个 core 顺序创建 enclave。结果显示，作者实验中 enclave 创建时间基本落在760 ms 到 770 ms之间，因此可以认为单个 enclave 顺序创建时比较确定。“稳定”不代表“快”。760–770 ms 对很多实时任务来说已经非常长。
对于软实时任务，也许还能接受；对于控制周期很短的工业控制、机器人控制，这个启动时间就明显太大。十、图 7：单线程 real-time enclave，PREEMPT_RT 仍有帮助，但帮助变小
论文第 6 页的Figure 7测的是单线程 high-priority enclave 启动总延迟。实验方法是：修改版 cyclictest 的任务每次醒来后创建 enclave，真正的计时点放在 enclave 内部。这样测到的是“从唤醒请求到 enclave 代码真正开始运行”的总时间。总延迟明显比普通 Linux 进程调度延迟大得多；但相比 mixed context 场景，PREEMPT_RT 的改善效果没那么显著。当 760 ms 级别的 enclave 创建成本成为主要部分时，Linux 调度优化带来的几十微秒、几百微秒级收益就被“淹没”了。十一、图 8 和图 9：两个 enclave 并发启动，问题暴露出来了
论文让 cyclictest 使用两个线程，在两个不同 core 上并发启动 real-time enclave。第 6 页的Figure 8比较了两个并发 enclave 线程下，stock kernel 和 PREEMPT_RT kernel 的总启动延迟。结果显示，两者差异并不明显。也就是说，PREEMPT_RT 对这个问题帮不上太多。第 6 页的Figure 9更直观，它在 PREEMPT_RT 下比较：结果很明显：两个线程时，延迟平均值更高，而且分布范围大幅变宽，部分延迟甚至接近数秒级。论文认为，这说明多个 enclave 同时创建会引入显著且不可预测的延迟。作者推测原因可能是 Keystone Secure Monitor 的 enclave 创建代码中存在不能被多个线程共享的临界区，例如使用spin_lock的独占访问区域。多个 enclave 并发启动时，这些锁可能导致等待、抢占和非确定性延迟。论文认为，如果要解决这个问题，可能需要像 PREEMPT_RT 改造 Linux 内核那样，对 Keystone SM 中的锁和临界区做细致检查和改造。单个 enclave 创建是“慢但稳定”；多个 enclave 并发创建则变成“更慢且不稳定”。
十二、附录图 10–13：进一步确认两类延迟不是一个量级
Figure 10比较了没有 PREEMPT_RT 时，后台有无 Keystone enclave 对 Linux 进程调度延迟的影响。整体看，Keystone 后台 enclave 仍没有显著改变普通 Linux 任务的调度延迟分布。Figure 11比较没有 PREEMPT_RT 时，一个和两个并发 enclave 启动线程的总延迟。趋势和主文 Figure 9 一致：两个并发线程明显更散、更不可预测。Figure 12和Figure 13把普通 Linux 进程调度延迟与 Keystone enclave 启动总延迟放在同一张图中对比。这个对比非常直观：普通 Linux 任务延迟通常在微秒级，而 Keystone enclave 启动总延迟接近 10^6 微秒，也就是秒级附近。对 real-time enclave 来说，瓶颈已经不是普通 Linux 调度，而是 enclave 创建和 Keystone 内部同步机制。
十三、这篇论文的核心贡献是什么？
这篇论文并没有提出一个全新的 TEE 架构，而是做了一件很重要的系统测量工作。第一，它把 Keystone 和 PREEMPT_RT 放到一起研究。论文指出，在此之前，PREEMPT_RT 与 Keystone 或其他 enclave 系统的组合尚未被系统研究。很多人讨论“TEE 能不能实时”时容易混在一起，但本文拆成了：作者修改 Keystone build 流程以支持 PREEMPT_RT，也修改 cyclictest 以测量 enclave 内部启动时间，并使用 stress-ng、iperf3 等工具模拟高负载。论文还说明相关代码和脚本以 artifact 形式开放。十四、给科研小白的重点理解
读这篇论文时，不要一开始就陷入所有实时系统术语。可以抓住三个问题：测的是latency，尤其是高优先级任务从“应该被唤醒”到“实际开始运行”的延迟。一个系统平均延迟低，但偶尔突然卡 1 秒，对实时控制来说可能是灾难。所以论文用 log-log histogram 看延迟分布是否集中、是否有长尾。Keystone 后台 enclave 不明显影响普通 Linux 实时任务；但把实时任务放进 enclave 后，尤其多个 enclave 并发启动，Keystone 创建流程会成为主要延迟来源。十五、这篇论文对系统设计有什么启发？
如果你要设计一个“安全 + 实时”的 RISC-V 系统，可以从这篇论文得到几个工程建议。第一，能不频繁创建 enclave，就不要频繁创建。Figure 6 已经显示，单个 enclave 创建大约 760–770 ms。对于高频实时任务，动态创建 enclave 很可能不合适。论文提到已有工作提出 enclave application cache，可以降低重复任务启动时间。虽然这不是本文重点，但对实际系统非常重要。第三，把实时采集/控制留在 Linux RT 侧，把机密处理放到后台 enclave，可能更现实。Figure 4 和 Figure 5 说明，在 mixed context 下 Keystone 对高优先级 Linux 进程干扰不明显。第四，如果必须 real-time enclave，需要进一步改造 Keystone Secure Monitor。尤其要分析 SM 中 spin_lock、临界区、PMP 配置、上下文切换路径，看哪些地方会导致并发启动时长尾延迟。
十六、局限性：这篇论文没有解决什么？
这篇论文主要关注enclave startup latency，也就是 enclave 启动相关延迟。它没有全面解决 TEE 实时性的所有问题。论文也说明，timer、interrupt、availability 等更广泛问题留给未来工作。此外，实验平台是 HiFive Unmatched Rev. B，结果对其他 RISC-V SoC、其他 Keystone 配置、其他内核版本不一定完全一致。但它提供了一个很好的测量范式。结语：Keystone + PREEMPT_RT 可以做实时安全吗？
对于 mixed-criticality 场景，如果实时任务在 Linux PREEMPT_RT 侧运行，Keystone enclave 作为后台安全任务，整体是有希望的。如果实时任务本身必须在 enclave 中启动和执行，当前 Keystone 的 enclave 创建延迟，尤其是并发创建时的不可预测延迟，会成为明显障碍。这篇论文的价值在于，它把 TEE 研究从“能不能隔离、能不能证明安全”推进到了更工程化的问题：安全机制进入真实嵌入式和控制系统后，是否还能满足时间约束？
对于 RISC-V TEE 来说，下一步不仅要让 enclave 更安全，还要让 enclave 的启动、切换、调度更加可预测。安全和实时，必须一起设计。
10个月宝宝每天需要喝多少奶粉？