Non-Volatile Storage & Settings
Relevant source files
The following files were used as context for generating this wiki page:
Non-Volatile Storage (NVS) and the Settings subsystem in Zephyr provide a robust framework for persisting data across device reboots and power cycles. This system is critical for maintaining application state, device configurations, and security assets. The architecture emphasizes modularity and configurability, allowing developers to enable only necessary protocols and drivers to reduce the attack surface and optimize resource usage.
The system is integrated into Zephyr's security and safety frameworks, ensuring that persistent data—such as cryptographic keys and identity certificates—is handled with principles like "least privilege" and "fail-safe defaults." These mechanisms are essential for IoT devices where uncontrolled access to non-volatile data can be devastating.
Sources: doc/security/security-overview.rst:54-72, doc/security/secure-coding.rst:11-19
System Architecture and Integration
The storage and settings capabilities are part of the broader "OS Services" layer within the Zephyr system architecture. This layer sits between the low-level platform-specific drivers and the high-level application services.
The diagram shows the position of storage and settings within the Zephyr layered architecture.
Key Components
- OS Services: Contains generic implementations of I/O APIs, file systems, and the Settings subsystem.
- Platform Drivers: Low-level drivers that interface with physical flash memory or EEPROM.
- Configuration Management: Uses Kconfig to enable or disable specific storage features and protocols.
Sources: doc/security/security-overview.rst:193-205, doc/security/secure-coding.rst:83-88
Security Principles for Persistent Data
Persistent storage is a primary target for attackers. Zephyr applies several secure design standards to NVS and Settings:
| Principle | Application in Storage/Settings |
|---|---|
| Fail-safe defaults | Access is restricted by default; services must be explicitly enabled. |
| Least Privilege | Threads have the smallest subset of permissions required to access specific memory regions. |
| Economy of Mechanism | Modular code and abstracted APIs keep the design simple and small. |
| Open Design | Publicly accepted cryptographic libraries (like PSA Crypto via mbedTLS) are used for securing data instead of custom measures. |
Access Control and Isolation
Memory protection features partition address space (memory, peripheral space, etc.) to assign specific resources to individual threads. This prevents unauthorized threads from reading or tampering with sensitive persistent data.
Sources: doc/security/secure-coding.rst:43-70, doc/security/security-overview.rst:111-125
Configuration and Modularization
The Settings subsystem is highly configurable through Zephyr's Kconfig system. This modularity is a security feature, following the "less commonly used services off by default" paradigm to reduce exposure.
Modular initialization flow based on Kconfig definitions.
Kconfig Conventions for Storage
To maintain consistency, configuration symbols follow specific naming patterns:
- Drivers:
{Driver Type}_{Driver Name}(e.g.,FLASH_NRF). - Prompts: These use the reverse order for better UI filtering (e.g.,
NRF Flash driver). - Dependency: Symbols often depend on
DT_HAS_<node>_ENABLEDto ensure they are only active when the corresponding hardware is defined in the Devicetree.
Sources: doc/security/secure-coding.rst:126-136, doc/contribute/style/kconfig.rst:56-78
Safety and Certification
For safety-critical applications, storage mechanisms must be "auditable." This requires adherence to the IEC 61508 standard, particularly for Safety Integrity Level (SIL) 3.
Requirements and Traceability
Non-volatile storage features must have associated technical requirements that are:
- Verifiable: Testable through functional verification.
- Traceable: Linked from high-level system requirements down to the specific code implementation and test cases.
- Atomic: Each requirement defines a single specific behavior of the storage feature.
Structural Test Coverage
To meet SIL 3 / SC3 targets, the storage code must achieve:
- 100% Structural test coverage (entry points).
- 100% Statement coverage.
- 100% Branch coverage.
Sources: doc/safety/safety_overview.rst:44-55, doc/safety/safety_requirements.rst:64-75, doc/safety/safety_overview.rst:133-145
Persistent Data Lifecycle
The lifecycle of persistent data involves identification, protection, and eventual termination or updates.
Sequence of persistent data interaction between application and backend.
Asset Identification
In the security architecture, persistent data is categorized as assets, which include:
- User data.
- Authentication and encryption keys.
- Key generation data (RNG seeds).
- Security status information.
Sources: doc/security/security-overview.rst:318-335, doc/project/release_process.rst:228-232
Summary
The Non-Volatile Storage & Settings system in Zephyr is a highly modular, security-focused framework. By leveraging Kconfig for feature isolation, mbedTLS/PSA Crypto for data protection, and rigorous safety standards for traceability and testing, Zephyr ensures that persistent data remains secure and reliable throughout the device lifecycle.