Memory Management
Relevant source files
The following files were used as context for generating this wiki page:
Memory Management in Zephyr encompasses a variety of strategies for handling both volatile RAM and non-volatile storage. The system is designed for resource-constrained environments, emphasizing static allocation for safety-critical applications while providing standard dynamic allocation interfaces for portability. It integrates architectural protection features to ensure thread isolation and system integrity.
The scope of memory management includes dynamic memory allocation via standard C libraries, kernel-specific heap and slab management, and specialized key-value storage systems like Zephyr Memory Storage (ZMS). For systems requiring functional safety (IEC 61508), memory management may be restricted—for example, by disabling complete dynamic memory management—to minimize systematic error rates and ensure predictable behavior.
Sources: doc/develop/languages/c/index.rst:75-101, doc/safety/safety_overview.rst:155-165, doc/security/security-overview.rst:105-115
Dynamic Memory Allocation
Zephyr supports standard C dynamic memory management interfaces, including malloc and free. While these are implemented by the C standard libraries (such as minimal libc, newlib, or picolibc), they must conform to specific Zephyr-specific conventions.
Standard Library Implementation
Each supported C standard library manages its own memory heap. When userspace is enabled, memory blocks must be allocated within the z_malloc_partition memory partition. For native Zephyr applications, it is recommended to use kernel-specific APIs like k_malloc instead of standard C functions to utilize advanced kernel features.
Sources: doc/develop/languages/c/index.rst:83-101
Memory Allocation Workflow
The following diagram illustrates how a memory allocation request is handled between the application, the standard library, and the Zephyr kernel hooks.
Memory Protection and Execution Security
Security in memory management is achieved through a combination of hardware-enforced protection and software-level isolation.
Core Protection Mechanisms
Zephyr implements three primary categories of execution protection:
- Memory Separation: Memory is partitioned into regions with specific attributes assigned to the owner (e.g., a specific thread).
- Stack Protection: Hardware stack guards detect and trap stack overruns, ensuring threads only access their own assigned stacks.
- Thread Separation: During context switches, the kernel enforces memory protection constraints to ensure threads only access authorized resources.
Sources: doc/security/security-overview.rst:105-115, doc/security/security-overview.rst:133-145
| Feature | Description | Requirement |
|---|---|---|
| Stack Guard | Hardware mechanism to trap stack overflows | Version 1.9.0+ |
| Thread Separation | Isolation between privileged and unprivileged environments | Version 1.10.0+ (x86), 1.11.0+ (ARM/ARC) |
| Memory Partitioning | Assigning memory regions/attributes to specific threads | Version 1.10.0+ |
Sources: doc/security/security-overview.rst:55-65
Zephyr Memory Storage (ZMS)
Zephyr Memory Storage is a specialized non-volatile key-value storage system. Unlike traditional file systems, ZMS is optimized for modern storage technologies like RRAM and MRAM that support direct overwrites without separate erase operations.
Sector Architecture
ZMS divides storage into sectors. Each sector contains Allocation Table Entries (ATEs) stored from the bottom up and raw data stored from the top down.
Allocation Table Entry (ATE) Structure
The ATE is a 16-byte structure used to track IDs, lengths, and locations of data.
| Byte Offset | Field | Description |
|---|---|---|
| 0 | crc8 | CRC check for the ATE header |
| 1 | cycle_cnt | Used for validation and wear leveling |
| 2-3 | len | Length of the associated data |
| 4-7 | id | 32-bit or 64-bit identifier |
| 8-11 | offset / data | Data offset or immediate data for small values |
| 12-15 | metadata | Data CRC or format-specific metadata |
Sources: doc/services/storage/zms/zms.rst:114-135
Safety and Quality Principles
For safety-certified applications (SIL 3 / SC 3), memory management follows strict architectural design principles to prevent systematic errors.
- Encapsulation: Safety-relevant memory components must be separated from non-safety-relevant ones to prevent repercussions.
- Configurability: Functionalities like dynamic memory management must be capable of being disabled via Kconfig if they are deemed unacceptable for a specific safety scope.
- Determinism: In safety contexts, modularity and layered models are used to ensure that memory interfaces are well-defined and auditable.
Sources: doc/safety/safety_overview.rst:155-165, doc/safety/safety_overview.rst:175-185
Summary of Storage Systems
Zephyr provides multiple storage options depending on the hardware and use case:
- ZMS: Best for RRAM/MRAM and devices with 64-bit ID requirements.
- NVS (Non-Volatile Storage): Recommended for classical flash with smaller footprints.
- FCB (Flash Circular Buffer): Best for First-In-First-Out (FIFO) access patterns.