Kernel Architecture & Scheduling
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
The Zephyr kernel is a high-performance, small-footprint real-time operating system (RTOS) designed for resource-constrained and embedded systems. It follows a monolithic architecture where the kernel and application services are compiled into a single static binary image, which minimizes the attack surface by removing the need for dynamic loaders. The kernel supports a wide range of architectures, including ARM (Cortex-M, Cortex-A, Cortex-R), Intel x86, RISC-V, and Xtensa, providing a consistent programming interface across diverse hardware platforms.
The primary role of the kernel is to manage system resources through multi-threading, interrupt handling, and synchronization services. The scheduling subsystem is highly configurable, supporting various algorithms such as preemptive scheduling, Earliest Deadline First (EDF), and Meta IRQ. This architecture ensures that applications can be tailored to meet specific real-time requirements while maintaining a small memory footprint.
Sources: doc/introduction/index.rst:4-21, doc/security/security-overview.rst:112-117, doc/introduction/index.rst:45-55
Kernel Architecture Overview
Zephyr's architecture is divided into an OS layer and an application layer. The OS layer contains the kernel core, platform-specific drivers, and generic OS services such as file systems and cryptographic libraries.
The diagram illustrates the high-level separation between user-specific application services and the core OS/Kernel components.
Sources: doc/security/security-overview.rst:159-173
Monolithic Design and Execution Protection
The kernel uses a monolithic design to improve security and performance. Execution protection is categorized into memory separation, stack protection, and thread separation. These constraints are enforced during context switches to prevent unauthorized access between threads or between user and privileged environments.
| Feature | Description |
|---|---|
| Monolithic Binary | Kernel and applications are linked into a single static image to eliminate dynamic loading vulnerabilities. |
| Memory Separation | Partitioning memory into regions with specific attributes based on thread ownership. |
| Stack Protection | Use of stack guards to detect and trap stack overruns. |
| Thread Separation | Splitting system into privileged and unprivileged environments with distinct resource access. |
Sources: doc/security/security-overview.rst:95-103, doc/security/security-overview.rst:133-150
Scheduling Subsystem
The scheduling subsystem is responsible for determining which thread executes on the CPU. Zephyr supports a comprehensive set of scheduling choices to accommodate different application needs.
Scheduling Algorithms
Zephyr provides multiple algorithms and queuing strategies:
- Preemptive & Cooperative Scheduling: Traditional priority-based scheduling where higher priority threads can preempt lower ones, or threads yield voluntarily.
- Earliest Deadline First (EDF): Dynamic priority scheduling based on deadline requirements.
- Meta IRQ: Implements "interrupt bottom half" or "tasklet" behavior for high-priority system tasks.
- Timeslicing: Enables round-robin time slicing between preemptible threads of equal priority.
Sources: doc/introduction/index.rst:60-70
Ready Queue Strategies
The kernel allows developers to choose the underlying data structure for the ready queue to optimize for specific use cases:
- Simple Linked-List: Best for systems with very few threads.
- Red/Black Tree: Efficient for systems with a large number of threads and diverse priorities.
- Traditional Multi-queue: A balanced approach for standard RTOS workloads.
Sources: doc/introduction/index.rst:71-76
Thread Lifecycle and State Transitions
The kernel manages thread states including ready, running, and waiting (pended). The k_poll API allows threads to monitor multiple events (like semaphores or FIFO) simultaneously, transitioning to a waiting state until one or more conditions are met.
This flow represents the standard transitions of a thread within the Zephyr scheduling environment.
Sources: doc/releases/release-notes-1.7.rst:24-28, doc/introduction/index.rst:47-49
Kernel Services & APIs
The kernel provides a suite of services for synchronization, data passing, and memory management.
Synchronization and Data Passing
Zephyr implements several primitives to facilitate communication between threads and ISRs:
- Semaphores: Binary and counting semaphores for resource tracking and synchronization.
- Mutexes: For mutual exclusion with priority inheritance support.
- Message Queues: For passing data between threads.
- Poll API: Consolidated event waiting via
k_poll.
Sources: doc/introduction/index.rst:50-58, doc/releases/release-notes-1.7.rst:24-28
Memory Allocation
The kernel supports both fixed-size and variable-size memory allocation:
- Memory Slabs: For fixed-size block allocation with deterministic timing.
- Memory Pools: For variable-size allocation, though dynamic memory management can be disabled in safety-critical configurations.
Sources: doc/introduction/index.rst:53-55, doc/safety/safety_overview.rst:165-170
Safety and Security Considerations
Functional Safety (IEC 61508)
The Zephyr Safety Committee aims for IEC 61508 SIL 3 certification using a modular approach. This involves a layered architecture and the ability to disable non-safety-relevant components via Kconfig.
Sources: doc/safety/safety_overview.rst:43-55, doc/safety/safety_overview.rst:147-155
Secure Design Principles
The kernel follows the principle of "Least Privilege," ensuring threads only have access to the resources required for their tasks. Secure coding guidelines enforce input validation and fail-safe defaults.
Sources: doc/security/secure-coding.rst:67-90, doc/security/security-overview.rst:184-192
Summary
The Zephyr Kernel Architecture provides a highly modular and configurable foundation for embedded development. By combining a monolithic design with robust scheduling options and comprehensive execution protection, it balances the performance needs of resource-constrained hardware with the rigorous requirements of safety and security standards.
Sources: doc/introduction/index.rst:4-10, doc/safety/safety_overview.rst:147-152