embOS-MPU
Comprehensive memory protection
embOS-MPU’s comprehensive memory protection tightens the security of embedded devices. All tasks are 100% sandboxed, making devices suitable for any safety-critical application.
Overview
embOS-MPU offers memory protection on top of the proven RTOS (Real-Time Operating System), embOS. Memory protection enhances the stability and safety of embedded applications, serving to simplify any certification process. It does this by protecting the operating system and tasks deemed privileged, 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.
So what might use cases look like? Think anything from battery-powered, single chip products to systems that demand ultra-fast response, flexibility and multiple tasks. Its field of application is also vast: medical equipment, automation, avionics and pretty much any application that is safety-critical.
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
The what & why of memory protection
“Memory protection” can be described as a prevalent mechanism for controlling memory access rights. It is part of most modern processor architectures and operating systems. Its main goal is to stop specific tasks from accessing memory that hasn’t been allocated to them. This prevents possible bugs or even malware contained in one task from affecting 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 operating system) 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
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 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 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).
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.
