RTOS/SEC
0 / 25

Field guide · 25 modules · avionics · automotive · medical

Security for systems that
cannot miss a deadline.

A real-time operating system fails two ways: it can be wrong, or it can be late. Securing one means defending confidentiality and integrity without ever stealing the microseconds a control loop is counting on. This guide walks the whole surface — kernel to key store — with code you can run and threats you can trace.

Start the 25 modules Try the scheduler lab
Modules
25
Runnable snippets
12+
Threat scenarios
9
SCHEDULE · rate-monotonic · 3 tasks
τ1 · 5ms · hi τ2 · 10ms · med τ3 · 20ms · lo

The 25 modules

Tap any card to open its briefing — a plain-language explanation, why it matters for real-time systems, and where the security holes actually are. Mark modules complete to track your run.

    Scheduler lab — where timing becomes a security property

    In an RTOS, an attacker rarely needs to crash you. Making a high-priority task miss its deadline is enough — that is a denial-of-service against physics. Build a task set below and watch rate-monotonic scheduling hold or break. This is the same math a certification reviewer runs by hand.

    CPU utilisation — · RMS bound for 3 tasks: —

    Bars are CPU time. A red notch is a job that ran past its deadline. Push utilisation over the bound and watch the low-priority task starve — that is priority inversion waiting to happen.

    Threat map · STRIDE across the RTOS stack

    Pick a layer of the stack to see what goes wrong there, the real-world incident it echoes, and the mitigation you'd put in front of a DO-178C or IEC 62443 reviewer.

      Code bench — the patterns worth memorising

      Vetted, minimal C for the mistakes that show up again and again in embedded security reviews. Each one pairs the flawed version with the hardened fix. Copy either.