SEGGER embOS-MPU
embOS RTOS with Memory Protection
embOS-MPU offers memory protection on top of the proven real-time operating system embOS. It significantly enhances both stability and safety of your embedded applications and thereby simplifies any certification process. The operating system and all tasks deemed privileged are memory protected and isolated from any ill affects of unprivileged tasks. Due to a fully compatible API, existing embOS applications may be adapted to embOS-MPU with minimal effort.
embOS-MPU can be used in any application from battery-powered, single chip products to systems demanding ultra-fast response, flexibility and multiple tasks. Typical fields include, but are not limited to medical equipment, automation, avionics, and further safety-critical applications.
- Ideal for safety-critical applications
- Available for any MCU containing a hardware MPU or MMU
Features
- Comprehensive memory protection
- Unprivileged tasks 100% Sandboxed
- Suitable for any safety-critical application
- Available for any microcontroller containing a hardware memory protection unit or memory management unit
- Simple and straightforward runtime configuration
- Easy to integrate in both new and existing products
- Supports device drivers for full control of peripheral accesses
- Unlimited number of privileged und unprivileged tasks possible
- MISRA-C:2012 compliant
Video: embOS-MPU Trial Version Example
This video walks through the embOS-MPU trial version example and demonstrates it running on a real system
Basic concepts of embOS-MPU
What is memory protection?
Memory protection is a prevalent mechanism to control memory access rights and is part of most modern processor architectures and operating systems. The main purpose of memory protection is to avert specific tasks from accessing memory that has not been allocated to them, thus preventing possible bugs or even malware contained in one task from affecting the entire system.
In order to achieve this, application tasks that could possibly affect other tasks or the OS itself must be restricted from accessing the whole memory, special function registers and the OS's control structures. For example, tasks that execute third-party code may be considered unsafe and should be restricted accordingly. Such application tasks must not run on the same privilege state as the OS, which runs in fully privileged mode and has access to all memory, peripheral and CPU features. Instead, these tasks must run in unprivileged state and have restricted access to specific memory locations only.
What is embOS-MPU?
embOS-MPU uses the hardware's memory protection unit as well as additional software mechanisms implemented with embOS-MPU to prevent one task from affecting the entirety of the system. This guarantees that even in case a bug occurs in one task, all other tasks and the operating system itself continue execution.
With embOS-MPU, all privileged tasks have full access to the whole memory. An unprivileged task, however, has specific access permissions to each distinct memory region. In order 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.
An application based on embOS-MPU therefore consists 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 reliability. - The second part is the application itself, which does not need to be verified for full reliability.
As it runs in unprivileged state, this part cannot affect the complete system.
Working with unprivileged tasks
By default, a newly created unprivileged task has read access to RAM and ROM, but may execute code in ROM only, while write access is restricted to its own task stack. In order 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 necessary to access peripherals from within such task, e.g. for using a UART, SPI, or port pins. Device drivers can be provided by SEGGER, but in most cases will be implemented by the user.
With embOS-MPU, a device driver consists of two parts: one part runs in privileged state and the other part runs in unprivileged state. The actual peripheral access is performed in the privileged part only, and embOS-MPU ensures that there is only one explicit and safe way to switch from the unprivileged part to the privileged one.
Access to further memory regions
An unprivileged task may be granted access to additional memory regions, e.g. when a task needs to write LCD data to a framebuffer in RAM and a device driver is deemed inefficient for this purpose. Access permissions are fully configurable in regards 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 privileged state.
MPU violation management
In case an unprivileged task violates its access restrictions or otherwise triggers a fault exception, it is automatically suspended and an optional user callback function is executed to inform the application about this. This callback may also perform further actions in regards to that task, e.g. restarting it or even terminating it completely.
Supported cores and compiler
embOS-MPU currently has support for Cortex-M architecture and the SEGGER Embedded Studio IDE. SEGGER is continuously adding new targets. However, SEGGER can port the system to the target of your choice, ensuring high quality and extensive testing. Please contact us at info@carnica-technology.com with any target requests or questions.
Trial version
Download an embOS-MPU trial version and get your first application running within a few minutes!