TEE × RTOS 論文閱讀分析：很多 MCU trusted computing 真正缺的，不是更強隔離，而是 secure world 別把時間一起凍住
本文由 AI 產生、整理與撰寫。
論文基本資訊
- 論文標題：Resolving Conflicts Between RTOS Timekeeping and Uninterruptable Trusted Computing
- 作者：Antonio Joia Neto、Carlos O. A. M. Correia、Felipe M. G. França、Paulo R. M. Maciel、Vinicius F. Mota
- 年份：2026
- 來源：arXiv:2604.24277
- 論文連結：https://arxiv.org/abs/2604.24277
- DOI：10.48550/arXiv.2604.24277
- 主題：Trusted Execution Environments、RTOS Security、Embedded Security、Microcontrollers、TrustZone-M、Real-Time Systems
很多 MCU 上的 trusted computing 真正缺的，不是再多一層隔離，而是secure world 在保護自己時，別把 non-secure world 的時間一起凍住。
這篇 Resolving Conflicts Between RTOS Timekeeping and Uninterruptable Trusted Computing 看起來像很窄的系統 paper，但其實切得非常準。作者盯上的不是傳統那種「TEE 會不會被繞過」的大題，而是一個更尷尬、也更容易被忽略的現實：在低功耗微控制器上，很多 RTOS 靠 SysTick 這類週期中斷維持時間感，而很多 trusted computing service 又要求 secure execution 期間不能被 non-secure side 打斷。
這兩件事單看都合理，放在一起卻會撞車。你越想保證 secure operation 的 atomicity，non-secure RTOS 的時間就越可能失真；而時間一失真，排程、timeout、週期任務、deadline 判斷就會一起歪掉。
這篇最值得看的地方，是它把「安全隔離」和「即時系統時間一致性」之間的衝突講成一個正式的系統問題：不是安全多加一點就好，因為你可能先把系統對時間的基本信任做壞。
它在打哪個痛點？
在 TrustZone-M 這類架構裡，secure 與 non-secure 世界雖然隔離，但硬體資源不是全部各自獨立。像 interrupt controller 這種關鍵資源，本來就會被兩邊共用。這代表一件很麻煩的事：如果 secure world 正在做一段不希望被 non-secure world 干擾的敏感操作，那麼來自 RTOS 的 tick interrupt 可能就得先被擋住。
對安全性來說，這很合理。對 RTOS 來說，這很致命。
因為很多 embedded RTOS 並不是把時間當成可有可無的 UI 元素，而是把它當成整個系統行為的節拍器：
- task scheduling 要靠 tick 前進
- timeout 與 watchdog 協調 要靠時間基準
- 週期性感測 / 控制迴圈 要靠時間一致性
- 即時性保證 本質上就是在賭時間不會亂掉
所以這篇的核心不是「interrupt 少來幾次會不會有點慢」，而是：如果 secure service 每次進場都偷走幾個 tick，non-secure RTOS 看到的世界就不再是單調一致的時間世界。
作者怎麼拆這個問題？
作者的 framing 很實在。他們先承認矛盾無法靠口號解決：你不能同時說「secure operation 期間不要被 non-secure 世界打斷」，又要求「non-secure RTOS 的 tick 完全照常發生而且毫無偏差」。既然如此，問題就變成：能不能由 secure world 自己替 non-secure world 把消失的時間補回去？
他們提出的方法就是一個 secure-driven time synchronization mechanism。簡單講：
- secure world 在自己執行期間量測經過了多少真實時間
- 在準備把控制權交回 non-secure world 前
- 直接把 RTOS 內部 time-keeping data structure 補上對應數量的 missed ticks
- 接著再重新開放 interrupt，讓 non-secure side 繼續跑
這個想法看起來樸素，但其實很關鍵。因為它不是硬要讓 SysTick 在 secure critical section 期間照常工作，也不是要求底層 RTOS 大改架構，而是把問題改寫成：secure world 既然是造成時間缺口的一方，那就由 secure world 負責把時間帳補平。
這篇最值得記的 framing：很多 trusted computing 真正壞掉的，不是機密性，而是時間語義
安全研究很常把 attention 放在 confidentiality、integrity、attestation、key isolation 這些看起來比較「正統」的層面，但這篇提醒了一個被低估的點：在 cyber-physical 與 embedded 環境裡，時間本身就是系統語義的一部分。
如果 secure mechanism 讓 non-secure side 的 clock semantics 被默默扭曲，後果不一定會立刻被寫成 CVE，卻可能慢慢侵蝕系統正確性：
- 排程 jitter 累積
- 超時機制誤判
- 控制迴圈節奏偏移
- 跨世界事件順序理解錯亂
換句話說，很多「安全元件已經正確隔離」的系統，最後還是可能因為時間被做壞而整體不可信。 這是我覺得這篇很值得看的地方：它不是在挑戰 TEE 的必要性，而是在逼你承認 secure isolation without temporal coherence 其實是半套。
為什麼這種方法比「改 RTOS」更有現實感？
作者強調，他們的方法不需要修改底層 RTOS，而且執行時額外開銷不顯著。這點很重要，因為 embedded / industrial 世界最怕的往往不是理論不夠漂亮，而是 deployability 太差。
你如果提出的方案需要：
- 重寫 RTOS scheduler
- 大改既有 driver 與 timer stack
- 要求所有應用都重新驗證 timing behavior
- 或逼產品線全面升級硬體
那就算論文上成立，現場通常也不會買單。相較之下，這篇方法比較像是把修補責任壓在 secure runtime 這一側：既然是你在 critical section 期間禁止 non-secure tick 前進，那就由你用最小侵入的方式補償它。
這種設計哲學很成熟：不要把安全修補的成本外包給整個既有 real-time software ecosystem。
它對 embedded security 的啟發其實比題目更大
表面上，這是在講 TrustZone-M + RTOS + SysTick 的特定衝突；但它背後其實在講一個更普遍的安全工程原則：
只要某個安全機制會暫停、延後、批次化或重排序另一個子系統觀察世界的方式，你就不能只驗證它有沒有保護到資料，還得驗證它有沒有把那個子系統對世界的時間感做壞。
這個原則其實能外推到很多地方：
- hypervisor / VM introspection 對 guest timing 的影響
- 安全監控代理程式對工控控制迴圈的 jitter 影響
- agent governance middleware 對工具調用延遲與 sequence semantics 的干預
- 安全 broker 對 message-driven system event ordering 的扭曲
也就是說，安全控制如果改寫了系統的時間結構，它就不只是控制措施，也是系統行為塑形器。
防守方該從這篇記住什麼？
- 第一，TEE 不是加上去就結束，還要看它怎麼和 real-time semantics 共存。
很多 MCU / IoT 產品不是單純算資料，而是要在 deadline 內對世界反應。 - 第二，共用硬體資源的跨世界副作用要被當成正式 attack / failure surface。
interrupt、timer、DMA、bus arbitration 這些「共享但不是資料」的資源，常常就是系統失真的源頭。 - 第三，安全補償機制最好由造成干擾的一側承擔。
如果是 secure critical section 阻斷了 non-secure tick，那補償邏輯就應該盡量留在 secure side，而不是把一堆補丁丟給應用開發者。
這篇的限制也要看清楚
當然，這篇不是萬靈丹。它處理的是「missed ticks 如何被補償」這種時間同步問題，但不是所有 real-time side effect 都能靠補 tick 解決。若某些工作負載對 interrupt latency、瞬時 response time、外設事件精準時間戳非常敏感，那麼即使最後帳面 tick 被補回來，行為上仍可能受到影響。
另外，secure world 對 RTOS data structure 的更新本身也需要非常小心：一旦不同 RTOS 實作細節不同、或後續版本變動，補償機制本身也可能成為新的 maintenance burden。
但這不影響它的價值。因為它至少把一件原本常被當成 implementation nuisance 的問題，升級成了正式的系統安全設計議題。
一句話總結
這篇論文最值得看的地方，不是它又替 TrustZone-M 找到一個優化技巧，而是它指出很多 MCU trusted computing 真正缺的，不只是把 secure world 關得更緊，而是別讓這份安全性以「non-secure world 從此失去正確時間感」為代價；在 embedded 系統裡，保住時間語義，往往跟保住隔離本身一樣重要。