💻 computer science

Resolving Conflicts Between RTOS Timekeeping and Uninterruptable Trusted Computing

This paper resolves the conflict between real-time operating system timekeeping and atomic trusted computing services on low-power microcontrollers by introducing a Secure-driven synchronization mechanism that compensates for missed interrupts without modifying the RTOS or incurring significant runtime overhead.

Original authors: Antonio Joia Neto, Amarin Amarin, Norrathep Rattanavipanon, Ivan De Oliveira Nunes

Published 2026-04-28

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Antonio Joia Neto, Amarin Amarin, Norrathep Rattanavipanon, Ivan De Oliveira Nunes

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a high-security bank vault (the Secure World) and a busy, bustling office next door (the Non-Secure World).

In this office, there is a very important clock on the wall that ticks every 10 milliseconds. This clock is the heartbeat of the office. It tells the workers when to start a task, when to take a break, and when to stop a machine. This is how RTOS (Real-Time Operating Systems) work on tiny computer chips in devices like smart home gadgets or medical equipment.

The Problem: The "Uninterruptible" Vault

Now, imagine the bank vault needs to perform a critical, secret operation—like changing the combination lock or verifying a signature. To ensure no one can sneak in and tamper with the process, the vault manager locks the doors and turns off the intercom system for the entire duration of the job.

In computer terms, this is called atomic execution. The Secure World disables all interrupts (including the office clock's signal) to protect its secrets.

Here is the conflict:
While the vault is locked down and the intercom is off, the office clock keeps ticking in the real world, but the office workers don't hear it.

If the vault job takes a long time, the clock might tick 100 times while the workers are deaf to it.
When the vault finally opens and the intercom turns back on, the clock hardware only remembers one missed tick. It says, "Okay, here is one tick!" and moves on.
The other 99 ticks are lost forever.

The office workers now think only 10 milliseconds have passed, but in reality, 1,000 milliseconds have gone by. Their internal schedule is now completely out of sync with reality. If they are controlling a robot arm or a car brake, this "time drift" could cause them to move too late or too fast, leading to accidents.

The Paper's Solution: The "Secret Timekeeper"

The authors of this paper realized that simply waiting for the office to catch up doesn't work because the clock hardware can't remember all the missed ticks.

They proposed a clever workaround: The Vault Manager becomes the Office Timekeeper.

Here is how their system works:

Before the Vault Locks: The office clock's signal is rerouted. Instead of going to the office workers, it goes directly to the Vault Manager.
During the Lockdown: Even though the office workers are silent, the Vault Manager is listening to the clock. Every time the clock ticks, the Manager counts it.
- Analogy: Imagine the Manager has a notepad. Every time the clock ticks, they write down "1, 2, 3..." on the pad.
After the Vault Opens: Once the secret job is done, the Manager hands the notepad back to the office.
- Instead of just saying "Here is one tick," the Manager says, "I counted 100 ticks while you were busy. Here is the updated schedule for all 100 of them."
The Result: The office workers instantly update their internal clocks, release any tasks that were supposed to start during the delay, and get back on track.

Why This is Special

The paper highlights three main achievements:

No Construction Needed: They didn't have to rebuild the office (the operating system) or install new clocks (hardware). They just changed who listens to the clock during the vault job.
It's Invisible: The office workers (the applications) don't know the vault was ever closed. They just see that time passed correctly.
It Works for Real Machines: The authors tested this on actual hardware (like the Raspberry Pi Pico 2 and STM32 chips) and even simulated a motor controller. They showed that without this fix, the motor would drift and lose control, but with the fix, it runs perfectly smooth.

The Bottom Line

In a world where tiny computers need to be both super secure (locking down to protect secrets) and super fast (keeping perfect time for real-time tasks), these two goals usually fight each other.

This paper provides a "translator" that lets the secure world count the time for the insecure world while it's busy, ensuring that when the secure job is done, the rest of the system knows exactly what time it is and can keep working safely.

1. Problem Statement

The paper addresses a critical conflict between Trusted Execution Environments (TEEs) on low-power microcontrollers (specifically ARM TrustZone-M) and Real-Time Operating Systems (RTOS).

The Conflict: TEEs (Secure World) require certain security services (e.g., cryptographic operations, remote attestation, hot-patching) to execute atomically to prevent tampering. To ensure atomicity, the Secure World disables all Non-Secure interrupts during execution.
The Consequence: The Non-Secure World (where the RTOS resides) relies on periodic SysTick interrupts to maintain its internal notion of time, drive task scheduling, and manage timeouts. When the Secure World disables interrupts, SysTick events are blocked.
The Mechanism of Failure: The Nested Vectored Interrupt Controller (NVIC) can only buffer one pending interrupt. If a secure service lasts longer than one SysTick period ( $T_{tick}$ ), the first missed tick is buffered, but all subsequent ticks during that interval are silently discarded.
Impact: This results in time drift where the RTOS undercounts time. This is not merely a clock error; it causes:
- Missed task releases and delayed execution.
- Incorrect timeout expirations in synchronization primitives.
- Failure of software timers.
- Degradation of control systems (e.g., motor control) due to silent timing mismatches between the controller's logic and physical reality.

Prior work largely overlooked this issue, assuming that fast atomic operations would not significantly impact timekeeping, or failing to model the cumulative effect of tick loss in a multi-domain environment.

2. Methodology: Secure-Driven Time Synchronization

The authors propose a lightweight mechanism where the Secure World takes responsibility for tracking and compensating for missed SysTick ticks, ensuring the Non-Secure RTOS resumes with a consistent state.

Core Design Principles

No RTOS Modifications: The solution requires no changes to the underlying RTOS kernel or application logic.
Secure World Execution: The Secure World intercepts SysTick events while atomic services are running.
State Reconstruction: Instead of just correcting a counter, the Secure World reconstructs the semantic effects of the missed ticks on the RTOS kernel.

Technical Implementation

Interrupt Redirection: When a secure service starts, the Secure World reconfigures the NVIC to route the Non-Secure SysTick interrupt to a Secure World handler (the "Secure NS SysTick Handler").
Tick Interception:
- The Secure handler runs on every SysTick expiration that occurs during the atomic service.
- It increments an internal counter ( $n$ ) representing the number of missed ticks.
- It updates the Non-Secure tick counter variable directly using pre-extracted addresses.
Reconstruction Sweep (Post-Service): Once the secure service completes and interrupts are re-enabled, the Secure World performs a single "sweep" to apply the cumulative effects of the $n$ $n$ missed ticks to the Non-Secure kernel:
- Delayed Tasks: Promotes blocked tasks to the ready list if their wake time $\le$ (current tick + $n$ ).
- Software Timers: Posts a command to the Non-Secure timer task queue to fire all expired timers that would have triggered during the missed interval.
- Round-Robin Scheduling: Calculates how many time-slice rotations should have occurred and advances the ready-list pointer accordingly.
- Rescheduling: If a higher-priority task became ready, it triggers a PendSV to force an immediate context switch upon return.
Security: The handler validates all pointers before dereferencing Non-Secure memory to prevent a compromised Non-Secure World from redirecting pointers into Secure memory.

3. Key Contributions

Characterization of Cross-World Timing Drift:
- Formalized a mathematical model for tick loss based on atomic service duration ( $A_i$ ), SysTick period ( $T_{tick}$ ), and execution frequency.
- Demonstrated that drift accumulates linearly and can be significant even for short atomic operations if they occur frequently.
Cross-World Time Reconciliation Mechanism:
- Proposed a novel architecture where the Secure World acts as a "timekeeper" for the Non-Secure World during atomic intervals.
- Achieves full state consistency (not just counter correction) without modifying the RTOS.
Empirical Validation & Case Study:
- Validated the model on FreeRTOS and Zephyr running on ARM Cortex-M33 hardware (Raspberry Pi Pico 2 and STM32L552).
- Conducted a closed-loop control system case study (DC motor speed and position control) to demonstrate the safety implications of uncorrected drift.

4. Results

Drift Elimination: The proposed mechanism completely eliminated time drift. In experiments, the Non-Secure tick counter remained aligned with the Secure World reference time within a single tick, even after thousands of atomic service invocations.
Overhead:
- CPU Cycles: The Secure handler adds minimal overhead (~120 cycles on FreeRTOS, ~172 on Zephyr).
- Code Size: The implementation adds only ~118 lines of code (FreeRTOS) or ~280 lines (Zephyr) to the Secure World.
- Latency: On platforms with a shared SysTick, there is no observable interrupt latency increase.
Control System Impact:
- Uncompensated: In a DC motor speed control experiment, uncorrected drift caused the Root Mean Square Error (RMSE) to increase from 6.55 to 8.02 rad/s. In a position control experiment, a single missed release caused a peak position deviation of 56 mrad (3.21°).
- Compensated: With the mechanism enabled, the control system performance matched the baseline (no interference) exactly, proving that the mechanism preserves real-time guarantees.

5. Significance

This work is significant because it bridges a critical gap in the deployment of TEEs on safety-critical, real-time embedded systems.

Safety Assurance: It demonstrates that TEEs can coexist with hard real-time requirements without compromising system safety or control loop stability.
Practicality: By requiring no hardware modifications and no changes to existing RTOS kernels, the solution is immediately deployable on current TrustZone-M devices.
Paradigm Shift: It challenges the assumption that secure atomic execution is "transparent" to the rest of the system, highlighting that timekeeping is a shared resource that requires explicit synchronization across security domains.

In conclusion, the paper provides a robust, low-overhead solution to a previously unaddressed vulnerability in TrustZone-M architectures, ensuring that security services do not inadvertently degrade the temporal correctness of real-time applications.