embOS-MPU
Comprehensive memory protection
embOS-MPU adds comprehensive memory protection to SEGGER's proven embedded RTOS family, embOS. It tightens the security of embedded devices by sandboxing all tasks, making applications reliable and suitable for any safety-critical system.
Overview – Reliable memory protection for the embedded RTOS
embOS-MPU offers robust memory protection on top of the proven embOS real-time operating system (RTOS). RTOS memory protection enhances the stability and safety of embedded applications, directly simplifying any safety-certification process. It works by protecting the operating system and privileged tasks, isolating them from the negative effects of unprivileged tasks.
Thanks to a fully-compatible API, existing embOS applications can be adapted to embOS-MPU with minimal effort.
This makes it ideal for everything from battery-powered, single chip products to complex systems that demand ultra-fast deterministic RTOS performance. Its field of application is vast: medical equipment, automation, avionics and safety-critical systems.
Please note: Should requirements include certification, take a look at embOS-Safe.
SEGGER embOS-MPU introduction
Key features
- Easy integrations into new & existing products
- Simple, straightforward runtime configuration
- Availability for any MCU containing a hardware MPU or MMU
How embOS-MPU works: The guardian of memory
“Memory protection” is a critical mechanism for controlling memory access rights on modern processors. In an RTOS in an embedded System, its main goal is to stop specific tasks from accessing memory that hasn’t been allocated to them. This prevents bugs or malware in one task from affecting stability of the whole system.
For memory protection to work, application tasks that may affect other tasks (or the OS itself) must be restricted from accessing things like the entire memory, special function registers and the OS’s control structures.
Example: A task that executes third-party code may be considered unsafe and therefore restricted. This type of application task should not run in the same privileged state as the OS, which runs in fully privileged mode and has access to all memory, peripheral and CPU features. Instead, this type of task must run in an unprivileged state. It only gets restricted access to specific memory locations.
The Guardian of Memory — What embOS-MPU does
embOS-MPU uses the hardware’s memory protection unit in addition to its own implemented mechanisms to prevent one task from affecting the whole system. It also guarantees that should a bug occur in one task, all other tasks (and the embedded RTOS itself) will continue executing. Each privileged task therefore enjoys full access to the whole memory. Any unprivileged task only has specific access to each distinct memory region.
Should peripherals, additional memory locations, OS control structures or device drivers need to be accessed, embOS API may be called from within an unprivileged task.
Applications based on embOS-MPU therefore consist of two distinct parts.
- The first part runs in privileged state: It initializes the MPU settings and includes the device drivers. This part contains critical code and must be verified for full security.
- The second part is the application itself: It runs in an unprivileged state and cannot affect the complete system. This part does not need to be verified for full security.
Working with unprivileged tasks in your RTOS application
Newly-created unprivileged tasks have read access to RAM and ROM by default. They may also execute code in RAM and ROM. Write access, however, is restricted to its own task stack. To access peripherals, additional memory locations and OS control structures, device drivers as well as specific embOS API may be called from within an unprivileged task.
Access to peripherals
In a default configuration, an unprivileged task has no access to any peripheral. A specific device driver is needed to access peripherals from within such a task, for example, when using UART, SPI or port pins. SEGGER can provide device drivers, but it is mostly the users who implement them.
With embOS-MPU, a device driver consists of two parts:
- One part that runs in the privileged state.
- One part that runs in the unprivileged state.
Actual peripheral access is performed in the privileged part only. embOS-MPU ensures that there is only one explicit and safe way to switch from unprivileged to privileged.
Access to other memory regions
You can grant an unprivileged task access to additional memory regions. For example, a task may need to write LCD data to a framebuffer in RAM, but a device driver is deemed inefficient for this purpose. Access permissions are fully configurable in regard to read access, write access and code execution.
Access to OS objects
An unprivileged task has no direct or indirect write access to embOS objects. However, indirect write access to these objects via embOS-MPU API may be granted for each individual object. This requires all objects to be created in a privileged state.
MPU violation management
Should an unprivileged task violate access restrictions or trigger a fault exception by some other means, it is automatically terminated. An optional user callback function is then executed to notify the application. This callback may also perform further actions with regards to that task (such as restarting the whole system). The core task scheduling in RTOS operations remains unaffected, as the RTOS and other tasks are protected.
Licensing
embOS-MPU is available under various Embedded Software License models and delivered in source code packages. With a wide range of licensing options, embOS-MPU can fulfill commercial requirements as well as technical requirements. All licenses are one-time payments. embOS-MPU is royalty-free and not subscription-based. This makes the software a part of the equipment expenses, keeping the costs static.
The embOS-MPU licenses include:
- 6 months of updates and support by SEGGER's Embedded Experts
* Applies to second seat/product and all additional seats/products of the Single Product License and Single Developer License.
