Security Challenges, Threats & Mitigation

1. OS Security Issues in RTOS
Security Challenges, Threats & Mitigation

2. Introduction to RTOS Security
• RTOS used in embedded systems with real-
time requirements.
• Critical for medical, automotive, military, and
industrial systems.
• Security is vital due to system sensitivity and
connectivity.

3. Security Challenges in RTOS
• Limited resources: CPU, memory, power
constraints.
• Real-time deadlines: security must not impact
timing.
• Lack of MMU: weak memory protection and
isolation.

4. Security Threats in RTOS
• Code Injection via buffer overflows.
• Denial of Service (DoS) by task flooding.
• Privilege Escalation to gain unauthorized
access.
• Task Hijacking to control RTOS execution.
• Firmware Tampering leading to system
compromise.

5. Code Injection
• Malicious code inserted through vulnerable
tasks.
• Often occurs due to lack of input validation.
• Buffer overflows are a common entry point.
• Prevention: Stack protection, input
sanitization, MPU.

6. Denial of Service (DoS)
• Attacker overloads system with tasks or
requests.
• Starves critical tasks of CPU time or resources.
• Results in deadline misses or task failures.
• Prevention: Task prioritization, resource
quotas, watchdog timers.

7. Privilege Escalation
• Unauthorized access to higher-level privileges.
• Compromises kernel or system-level tasks.
• Prevention: Least privilege principle, memory
protection, secure APIs.

8. Task Hijacking
• Attacker takes control of a legitimate task.
• Can redirect execution or steal data.
• Prevention: Task isolation, stack canaries,
authentication mechanisms.

9. Firmware Tampering
• Altered firmware modifies system behavior or
injects malware.
• Can persist across reboots and go undetected.
• Prevention: Secure boot, digital signatures,
encrypted firmware updates.

10. Security Features in RTOS Design
• Access Control: privilege separation and capability
enforcement.
• Memory Protection: use of MPUs for task
boundaries.
• Secure Boot: ensure only signed firmware runs.
• Cryptographic Services: use AES, SHA for integrity
and authentication.
• Task Isolation: prevent data corruption and
unauthorized access.

11. Security in Communication
• TLS/DTLS for secure communication.
• Encrypt all data transfers.
• Avoid default or hardcoded credentials.
• Authenticate all communication endpoints.

12. RTOS Security Best Practices
• Apply regular firmware patches.
• Minimize attack surface by disabling unused
ports.
• Use secure inter-task communication with
integrity checks.
• Enable logs and audit trails for system behavior.
• Use watchdog timers to detect hangs and
attacks.

13. Interrupt Latency and Response
of Tasks as Performance Metrics

14. Performance Metrics Matter in
Real-Time Systems
• Ensures time-critical operations are executed on time
• Key metrics: Interrupt Latency and Task Response Time
• Relevant in systems like automotive, aerospace, robotics, and healthcare

15. Interrupt Latency
• Time between interrupt request (IRQ) and start of ISR
• Includes: detection time, context switching, ISR dispatch
• Critical for real-time responsiveness

16. Influences on Interrupt Latency
• CPU speed and architecture
• Interrupt priority and nesting
• Interrupt masking (disabled interrupts)
• RTOS overhead and scheduler efficiency

17. Task Response Time
• Time from task readiness to task completion
• Includes waiting time, scheduling delay, and execution time
• Measures timely task completion

18. Influences on Task Response Time
• Task priority and preemption
• Scheduling algorithm (FIFO, Round-Robin, Priority-Based)
• System load and number of active tasks
• Resource availability and I/O blocking

19. Comparison of the Two Metrics
• Interrupt Latency: Event to ISR start
• Task Response Time: Task ready to completion
• Measured in µs vs. ms respectively
• Latency is for reaction; Response is for completion

20. Use Cases in Industry
• Automotive: Airbags need low interrupt latency
• Medical Devices: Pacemakers require consistent response times
• Industrial Robots: Both metrics are critical

21. Phases of Interrupt Latency
• Interrupt Detection: Hardware signals the CPU
• Interrupt Acknowledge: CPU starts saving context
• ISR Dispatching: RTOS determines which ISR to run
• ISR Execution Begins: Actual code handling the interrupt

22. Maskable vs. Non-Maskable Interrupts
• Maskable Interrupts (MI): Can be disabled, subject to priorities
• Non-Maskable Interrupts (NMI): Cannot be disabled, critical failures
• NMIs are typically used for emergency conditions (e.g., power failure)

23. Context Switching and Its Impact
• Occurs during ISR or task switches
• Includes saving/restoring CPU registers and state
• Can add significant delay to both latency and response time
• Minimizing context switches improves performance

24. Scheduling Techniques &
Response Time
• Rate-Monotonic Scheduling (RMS): Fixed priority, shorter period = higher
priority
• Earliest Deadline First (EDF): Dynamic priority, nearest deadline first
• Round-Robin: Equal time slices, not ideal for real-time tasks

25. Reducing
Interrupt Latency & Response Time
• Keep ISRs short and efficient
• Prioritize critical tasks and interrupts
• Use fast context switch mechanisms
• Optimize scheduler behavior in RTOS
• Avoid shared resources and blocking in ISRs

26. Analyzing Latency and Response Time
• Tools: Tracealyzer, FreeRTOS+Trace, Linux perf, ftrace
• Visualize ISR duration, task scheduling, and bottlenecks
• Use logic analyzers for hardware-level measurement

27. Case Study:
Automotive Braking System
• Sensor triggers wheel slippage interrupt
• ISR must run within ~100 µs
• Response task must adjust braking in <10 ms
• Timely execution ensures vehicle safety

28. Case Study:
Heart Rate Monitoring System
• Interrupt triggered every 800 ms for heartbeat signal
• ISR records signal and triggers analysis task
• Response time must be <100 ms for real-time alert
• Critical for patient safety in monitoring systems

29. Interrupt and Response Design Pitfalls
• Long ISRs blocking lower-priority tasks
• Unbounded response time due to poor scheduling
• Ignoring context switch overhead
• Not considering worst-case execution time (WCET)

30. Summary
• Interrupt latency = Time to start handling external events
• Task response time = Time to complete scheduled operations
• Both metrics are critical in real-time and embedded systems
• Proper tools, design strategies, and scheduling reduce delays