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
“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.
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.
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.
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.
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.
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.
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).