Memory protection in an RTOS
On processors with an MPU, KideRT can enforce which memory regions application code may access.
| Memory region | Thread A permission |
|---|---|
| Application code, accessed | Read + execute |
| Thread A stack | Read + write |
| Thread B stack | No access |
| Kernel data | No access |
| Shared buffer | Read + write |
Access permitted, Read permission granted
Thread A can read this code region under the illustrated policy. Write permission is not granted.
Memory access permissions
The target’s memory protection configuration defines which regions each part of the application may access. Permissions apply per thread, which gives thread isolation. Each thread reaches only the regions configured for it, so another thread’s stack and kernel data can be kept out of its reach.
Protect kernel state
Keep privileged kernel data outside the regions unprivileged application code can write.
Define application regions
Plan access to code, data and stacks. Match the separation you need to the regions the hardware can enforce.
Share through explicit permissions
Grant access to selected buffers and device registers where needed.
Memory protection faults
Fault detection and system recovery are separate design decisions.
A CPU access violates policy
The address, access type and privilege level are checked against the active region configuration.
The processor raises a fault
Exception handling follows the target architecture and fault configuration.
Software handles the event
Diagnostic capture and any stop, restart or reset behaviour belong to the implemented fault policy.
Hardware requirements for memory protection
The CPU, memory layout and KideRT port determine the protection configuration available to your application.
See supported processors- Hardware and port
- Confirm the exact device, protection hardware and supported KideRT configuration.
- Region budget and layout
- Account for region count, alignment and granularity when placing code, data, stacks and shared buffers.
- Privilege and peripherals
- Identify privileged code, device register access and the controls for DMA and other bus masters.
- Behaviour under test
- Exercise permitted and denied accesses. Record the fault path and measure any configuration or context switch overhead.
Memory protection limitations
Does memory protection catch every invalid access?
It checks accesses against the configured region permissions. A bad pointer that still points inside an allowed writable region can corrupt data there. Region protection does not provide object-level bounds checking.
Does a CPU MPU also control DMA?
DMA and other bus masters have their own access paths. Check the device’s system-level protection and peripheral configuration; CPU MPU permissions alone do not establish their access policy.
Can execution continue after the processor raises a fault?
That depends on the implemented handler, application state and recovery policy. The presence of memory protection alone does not establish that execution can continue or that an individual task can be restarted.
Memory protection requirements
Discuss your target, application boundaries and fault-handling requirements with our engineers.