Understanding MPU Usage in Microcontroller-based
Systems in the Wild
Wei Zhou*†

Le GuanZhouqi Jiang*

School of Computing
School of Cyber Science and Engineering
School of Cyber Science and Engineering
Huazhong University of Science and Technology Huazhong University of Science and Technology University of Georgia
Athens, USA
Wuhan, China
Wuhan, China

Abstract—As more and more microcontroller-based embedded
devices are connected to the Internet, as part of the Internetof-Things (IoT), previously less tested (and insecure) devices
are exposed to miscreants. To prevent them from being compromised, the memory protection unit (MPU), which is readily
available on many of these devices, has the potential to play animportant role in enforcing defense mechanisms. In this work,
we comprehensively studied the MPU adoption in top operating
systems for microcontrollers. Specifically, we investigate whether
MPU is supported, how it is used, and whether the claimed
security requirement has been effectively achieved by using it.
We conclude that due to the added complexities, incompatibility,and fragmented programming interface, MPUs have not received
wide adoption in real products. Moreover, although the MPU
was developed for security purposes, it rarely fulfills its designed
functionality and can be easily circumvented in many settings.
We showcase concrete attacks to FreeRTOS and RIoT in thisregard. Finally, we discussed fundamental causes to explain thissituation. We hope our findings can inspire research on novel
usage of MPU in microcontrollers.

I.

I NTRODUCTION

Deeply embedded systems, which are powered by microcontroller units (MCUs), have long been used in closed
environments, such as industrial plants and vehicle communication systems. The reliability and robustness of such systems
were persistently tested in the past decades. However, thesetests were conducted in a benign environment. That is, it isassumed that no adversary could actively penetrate the system.
Unfortunately, this landscape has changed as more and more
embedded devices are exposed to the Internet, where everyone
can launch attacks remotely.
Since these systems are typically programmed using system
programming languages such as C/C++, memory errors pose agreat threat to their security, especially considering that many
third-party libraries run at the same privilege level as that of
the core program. As a security mechanism, ARM, a leading
chip designer for MCU, proposed, designed, and implemented*Also with Hubei Key Laboratory of Distributed System, Hubei Engineering
Research Center on Big Data Security.
†Corresponding author.

Workshop on Binary Analysis Research (BAR) 2023
3 March 2023, San Diego, CA, USA
ISBN 1-891562-84-3
https://dx.doi.org/10.14722/bar.2023.23007
www.ndss-symposium.org

the memory protection unit (MPU) to protect their chips. The
MPU is a low-cost security extension to ARM MCUs thatsafeguards certain sensitive memory regions in case a piece ofcode is compromised. Therefore, it is a promising mitigation
technique to memory vulnerabilities. Other MCUs such as
MSP430 FRAM followed this design and implemented similar
hardware.
In this work, we comprehensively investigated the usageof MPU in top operating systems (OSs) for microcontrollers.
More specifically, we are interested in whether MPU is supported, how it is used, which kinds of security are claimed,
and whether they are effectively achieved. To our surprise, we
found MPU is seldom used in real products, although popular
OSs largely support it. We attribute this to four reasons.
First, MPU is typically a default off feature on OSs andneeds the developers to explicitly enable it. Second, the addedcomplexities and compatibility issues make the manufacturers
reluctant to invest in R&D. Third, the introduced overhead on
performance and resource consumption makes it unsuitable formission-critical tasks. Finally, although MPU was mostly used
for security purposes, it rarely fulfills its designed functionality
and can be easily circumvented in many settings. We showcase
a concrete attack to FreeRTOS and RIoT in this regard.
Looking forward, we discuss common pitfalls in using
MPU and give recommendations on fixing the reported concerns. We also discuss how future generations of hardware(ARM TrustZone for MCUs) can make MCU-based systems
more secure.
Responsible Disclosure. All the vulnerabilities described inthis paper have been reported to the corresponding vendors
with technical details. In particular, CVE-2021-43997 has been
confirmed and patched by AWS on 11/12/20211 .
II.

BACKGROUND

A. What Can MPUs Do?
ARM is a leader in the MCU market. Its Cortex-M series
processors which are based on the ARM-V7M or ARMV8M architecture consume a much lower silicon area andare highly optimized to be energy-efficient and responsive
to interrupts, making them ideal for mission-critical tasks
such as industrial applications. On the other hand, due to the
cost- and power-efficient design, Cortex-M processors sacrifice
1 https://www.freertos.org/security/security_updates.html.

security. For example, the memory management unit (MMU)
is absent, which has been used to in many security solutions
for commodity OSs [4].
As a stripped-down version of MMU, MPU enforces
lightweight access control for MCUs. Specifically, an MPU
provides a fixed number of hardware registers (e.g., eightin Cortex-M4), and enforces access control rules for the
specified memory region. Concretely, a region can have individual memory access permissions (e.g., read/write/execution)and memory attributes (e.g., cacheability and shareability),
depending on the privilege mode the code is running. In ARM
Cortex-M MCUs, only two privilege levels are supported,
corresponding to Ring 0 and Ring 3 in X86. If memory accessviolates the permissions programmed in MPU, the processor
generates a MemManage fault (which is usually escalated intoa HardFault). The MPU has been supported in mainstream
ARM MCUs.
B. How to Program MPUs?
ARMv7-M. ARMv7-M is a widely adopted architecturein ARM MCU chips. It empowers the popular Cortex
M0/M0+/M3/M4/M7 series processors. MPUs in ARMv7-M
enforce access control based on regions (i.e., specific memory
range). Depending on the implementation, 8-16 memory regions can be supported. The range, permission, and attributeof each memory region are programmed via the Region Base
Address Register (RBAR) and Region Attribute/Size Register(RASR). Note that only privileged code can access theseregisters. Also, a region must be aligned. That is, a region
must start at an address that is multiple of its size. MPU
also imposes restrictions on the region size. More specifically,
the size of a region must be (1) at least 32 bytes, and (2) apower of two. Consequently, an arbitrarily sized region must
be emulated by an over-sized region (thus up to half of theregion size is wasted) or be pieced together by multiple smaller
regions (thus MPU registers are wasted). Large regions canbe further divided into eight equally sized sub-regions which
can be activated individually. However, these sub-regions all
inherit the same permission settings specified by the parent
region. This feature is achieved by configuring the sub-region
disable field (SRD) of RASR. Regions can overlap and highernumbered regions have precedence. Finally, there is a special
region with the least priority that maps the entire system memory. It only takes effect in privileged mode. When this regionis enabled, it sets the default access permissions for privilegedmode execution. In other words, when memory access does not
fall into any other regions, this default permission is enforced.
In contrast, when memory access occurs in unprivileged mode,
it must explicitly fall into a region. Otherwise, a fault is raised.
ARMv8-M. The ARMv8-M architecture is the successor of
the popular ARMv7-M architecture. It empowers the CortexM23/M33/M35P series MCUs, which has improved MPU
support. First, the number of MCU regions has increased.
Second, the restrictions on the region alignment are relaxed.
Third, the size restriction is removed because the ending
address of a region can be directly specified in the Limit
address. All of these improvements lead to more efficient usageof the system memory. A requested memory region that had
to be pieced together by several smaller hardware regions can

now be directly configured with only one hardware region.
Naturally, legacy features that were designed for efficient usageof system memory, such as the sub-region mechanism and theoverlapped region, have been abandoned.
III.

MPU U SAGE IN THE WILD

Taking advantage of the MPU, MCU-based embedded
systems can implement several memory-related security features, such as isolating critical services from untrusted codeor detecting memory errors. To understand how MPUs areused in real MCU products, we performed a comprehensive
survey, covering 30 top IoT operating systems (OSs) [34].
Some OSs (e.g., VxWorks) support both MCUs and traditional
processors. We only consider their MCU variants. Some OSs(e.g., Windows 10 IoT) only support traditional processors. We
did not include them in the table. Due to diverse terminologiesof the same security feature used by IoT OSs, we summarize
six unified names to refer to these commonly supported
security features, which can be easily mapped to traditional
memory isolation features.
•

Code Integrity Protection (CIP): Code regions canbe set as non-writable to prevent code injection andmanipulation.

•

Data Execution Prevention (DEP): Data regions
like stack or heap can be set as non-executable toprevent buffer overflow exploitation. CIP and DEP
map to WˆX [38] or executable-space protection [35]in general computing platforms.

•

Coarse-grained StackGuard (CSG): An inaccessible
memory hole is placed at the stack boundary todetect stack overflows. Note that CSG can only detect
overflows to the entire stack region, not confusing withtraditional StackGuard to function-level stack frames.

•

Kernel Memory Isolation (KMI): User mode (unprivileged) code cannot access any memory belonging
to the kernel space without invoking system calls,
which is similar to the user space and kernel space
separation [37] in modern OSs.

•

User Task Memory Isolation (TMI): User mode
(unprivileged) tasks can only access its own memory
except explicitly shared memory regions that belong
to other tasks or kernel, which is similar to the process
isolation [36] in modern modern OSs.

•

Peripherals Isolation (PI): Peripheral access is restricted to tasks that actually need it.

For each OS, we studied whether MPU is used and howeach of the six features is supported. In particular, a security
feature can be mandatory, optional or unsupported. An optionalfeature can further be default-on or default-off with configurations. For open-source OSs, we mainly relied on manual
review of the source code and documentation. Therefore, we
could get the most accurate and comprehensive results. For
propriety OSs, we can only resort to public resources suchas official and third-party websites. Interestingly, FreeRTOS
and embOS-MPU provides two separated versions with andwithout MPU support, and we list them as two different OSs.
The results are summarized in Table I. In the following sections
and Appendix A, we use some case studies to explain the table.

TABLE I.

Open-source

ProprietaryOS
Contiki [11]LiteOS [15]
RT-Thread [22]OpenWrt [20]TinyOS [5]Mongoose OS [17]FreeRTOS [8]FreeRTOS-MPU [7]
RIoT [21]Apache Mynewt [2]Zephyr [27]MbedOS [9]TizenRT [24]CMSIS-Keil RTX [6]Azure RTOS ThreadX [10]Micrium OS [16]Device OS [12]VxWorks [26]embOS [14]embOS-MPU [13]NXP MQX RTOS [18]
Nucleus RTOS [19]SafeRTOS [23]S UMMARY OF MPU USAGE AND ADOPTION ON MCU OS SMPU Support
None
None
None
None
None
None
None
Mandatory
Optional
None
Optional
Optional
Optional
Optional
Optional
None
None
None
None
Mandatory
Optional
Optional
Mandatory

CIP
Mandatory
Default-off
Default-on
Default-on
Default-off
Default-off
Default-off∅∅∅∅
Mandatory
Default-on∅
Mandatory

DEP
Mandatory
Default-on
Default-on
Default-off
Default-off
Default-off
∅
∅
∅
∅
∅
∅
∅
Mandatory

MPU Usage
KMI
TMI
Mandatory
Mandatory
Default-off
Default-off
Default-off
Default-off
Default-off
Default-off
∅
∅
∅
∅
∅
∅
∅
∅
Mandatory
Mandatory
Default-on
Default-on
Default-on
Default-on
Mandatory
Mandatory-: Not supported at the time of submission.

A. Case Study: RIoT
When all the MPU related protections are enabled(i.e., The macros of MODULE_MPU_NOEXEC_RAM and
MODULE_MPU_STACK_GUARD are set), RIoT enforces DEP
for the whole RAM and activates CSG using three MPU
memory regions.
DEP: RIoT enables the MPU region number 0 (recall thatlower number means lower priority) to cover the whole RAM
region (from 0x20000000 to 0x3fffffff) and set the permission as readable/writable but non-executable. Then, code
sections are explicitly granted the execution privilege.
CSG: RIoT defines the permission of the last 32 bytes (thesmallest MPU region) of the main stack as read-only via the
MPU region number 1. Similarly, when switching to anothertask, RIoT configures the last 32 bytes of the target task stack
as read-only via the MPU region number 1. With this 32byte memory hole, exhausting the stack memory will trigger
a MemManage fault.
B. Case Study: FreeRTOS-MPU
The basic FreeRTOS does not enable MPU. For the MPUenabled version, called FreeRTOS-MPU, we list the supported
security features in Table II.
CIP & DEP: The code sections are configured as read-only.
User task stacks and kernel data regions as configured as nonexecutable. Accesses to unmapped regions trigger memory
faults.
KMI: The privileged kernel APIs are located in the first partof the flash memory, which maps to the second MPU region.
It is set to be read-only in privileged mode, and inaccessible inunprivileged mode. The kernel-maintained data (e.g., current
control block) are located in a separated MPU region in RAM
which is readable and writable in privileged mode. In addition,
to expose kernel APIs (e.g., vTaskDelay) to unprivileged

CSG
Default-off
Default-off
Default-off
∅
∅
∅
∅
∅
∅
∅
∅

PI
Default-off
Default-off
∅
∅
∅
∅
∅
∅
∅
∅

∅: No public resource available to firmly decide.

TABLE II.
RegionNo.
0
1
2

M EMORY M AP OF F REE RTOS-MPU ON ARM V 7-M
Range

Usage

flash_segement_start-flash_segemnt_end
privileged_functions_start-privileged_functions_end
privileged_data_start-privileged_data_end

Non-writable Code Segment
Kernel APIs Isolation
Kernel Data Isolation

30x40000000-0x5fffffff

Non-executable Peripherals

4

User Task Stack

User Task Stack Isolation

TABLE III.
RegionNo.

Privilege
Mode
Privileged
Unprivileged
Privileged
Unprivileged
Privileged
Unprivileged
Privileged
Unprivileged
Privileged
Unprivileged

Permission
r-x
r-x
r-x
∅
rw∅
rwrwrwrw-

M EMORY M AP OF Z EPHYR ON ARM V 7-M

Range

Usage

0

Flash Region

Non-writable Code Segment

1

RAM Region

Kernel Object

2

Task Stack

Task Stack Isolation3

Last 32 Bytes on Stack Bottom

Stack Guard

Privilege
Mode
Privileged
Unprivileged
Privileged
Unprivileged
Privileged
Unprivileged
Privileged
Unprivileged

Permission
r-x
r-x
rw∅
rwrwr-∅

tasks, FreeRTOS-MPU takes advantage of software interrupt(i.e., SVC).
TMI: Tasks can be created to run in either privileged mode or
unprivileged (user) mode. A separated MPU region is reservedfor each user-mode task and is inaccessible for any other tasks.
By default, no memory is shared among user-mode tasks. To
share any data, the user-mode task should explicitly use thequeue or semaphore mechanisms provided by the kernel, which
consume up to three user-definable MPU regions.
C. Case Study: Zephyr
Zephyr is among IoT OSs that make heavy use of MPU.
It provides flexible protection based on users’ needs. We
summarize our findings in Table III.
CIP&DEP: The first MPU region maps to the flash memory
which stores program text and read-only data. It is configured

TABLE IV.
RegionNo.
01

M EMORY M AP OF T IZEN ON ARM V 7-M

Range
CommonBinaryUsage

Program Text

Non-writable Code Segment

Read-only Data

Non-writable Data Segment

2

Stack/Heap/Data

Common Stack/Heap/Data

3

Program Text

Non-writable Code Segment

Apps
BinaryRead-only Data

Non-writable Data Segment

5

Stack/Heap/Data

App Stack/Heap/Data

6

Last 32 Bytes on Stack Bottom

Stack Guard

7

User Task Stack

User Task Stack Isolation

4

Privilege
Mode
Privileged
Unprivileged
Privileged
Unprivileged
Privileged
Unprivileged
Privileged
Unprivileged
Privileged
Unprivileged
Privileged
Unprivileged
Privileged
Unprivileged
Privileged
Unprivileged

Permission
r-x
r-x
r-r-rwrwr-x
r-x
r-r-rwrwr-r-rwrw-

as read-only for all access. The SRAM region and any thread
stack are non-executable. Accesses to unmapped regions trigger memory faults.
KMI: Zephyr makes sure that all kernel objects in SRAM
(mapped in region #1) do not overlap with any user stacks(mapped in region #2). User tasks must invoke system calls toaccess kernel objects indirectly.
TMI&CSG: As mentioned before, Zephyr uses MPU region#2 to map task-specific stacks. Also, similar to RIoT, the last
32 bytes of each task’s stack are mapped to MPU Region#3, which is configured as read-only for privileged mode andinaccessible for unprivileged mode. Therefore, during a task
switch, the corresponding MPU registers need to be updated
for the target task. With this mechanism, a task cannot accessothers’ memory or exhaust its own allocated stack memory.
To add flexibility, a user task can use the memory domain togain access to additional memory. This memory region, which
is implemented by MPU, is inheritable and can be assigned tomultiple user or supervisor tasks.
PI: A peripheral driver instance is considered as a kernel
object. Therefore, its range is pre-configured to be inaccessible
by user tasks. To access peripherals, a user task must invoke
system calls.
D. Case Study: Tizen
All the MPU-enabled security features in Tizen are optional. They can be activated by the following macros:
CONFIG_APP_BINARY_SEPARATION, CONFIG_OPTIMIZE_APP_RELOAD_TIME, CONFIG_SUPPORT_COMMON_B
INARY and CONFIG_MPU_STACK_OVERFLOW_PROTECTI
ON. When fully enabled, the achieved security features are
summarized in Table IV.
CIP&DEP: Tizen sets all the code, including user tasks inapps binaries and common libraries as read-only. The dataregions of all tasks and common libraries are non-executable.
Unmapped memory regions is default region which is configured to be accessible only in privileged mode.

dynamically loading application binaries into the systems. To
achieve TMI for them, MPU regions #3, #4 and #5 are used.
E. Case Study: Mbed OS
The Mbed OS is backed ARM, which complies with the
Platform Security Architecture (PSA), an ARM initiative forsecurity standard of IoT devices. However, due to hardware
restriction, not every piece of hardware can fully support PSA,
including the popular ARM-V7M devices. Due to the missing
parts, Mbed OS for ARM-V7M only supports CIP for ROM
and DEP for SRAM.
IV.

Although using MPU offers obvious security benefits, wefound that MPU does not receive wide adoption in the wild.
For example, although FreeRTOS provides a variant with
MPU port, AWS mainly uses the non-MPU version in its
products [3]. In this section, we shed light on the root causeof this situation by discussing common pitfalls of using MPU
with real examples.
A. Weak Protection
While major IoT OSs adopt MPU to implement somesecurity features as discussed in Section III, we found thatthese claimed features do not always fulfil their designed
benefits. In certain scenarios, they can be easily bypassed. We
discuss how an attacker can break KMI in FreeRTOS-MPU
and invalidate MPU features in RIoT.
FreeRTOS kernel APIs are located in a region thatcan only be accessed in privileged mode. For compatibility, MPU-enabled FreeRTOS does not redesign its kernel
APIs to reflect MPU integration. Rather, it wraps the existing kernel APIs with the xPortRaisePrivilege andvPortResetPrivilege, which raise and drop its privilege
temporarily for kernel function invocations respectively. For
example, as shown in listing 1 if a user mode task needs fordelay for a certain time, it has to invoke MPU_vTaskDelay
which uses the xPortRaisePrivilege function to switch
to privileged mode with SVC software interrupt before invoking the real FreeRTOS kernel function vTaskDelay.
On the completion of vTaskDelay, it needs to drop theprivilege by invoking vPortResetPrivilege. However,since firmware binaries embed all the static compiled programs
as well as FreeRTOS kernel and system call APIs, the function
xPortRaisePrivilege can be easily located via reverseengineering. Once an attacker launches a control flow hijacking
attack (e.g., by exploiting a memory error) on any user modetasks, the hijacked task can escalate privilege via invoking
xPortRaisePrivilege, but never drop the privilege. With
the escalated privilege, the hijacked task can access any
resources on the device.
1
2
3

KMI: The kernel resides in the default region, which can only
be accessed in privileged mode. The user tasks communicate
with the kernel via system calls.

4
5
6
7
8

TMI&CSG: Tizen enforces TMI&CSG protection using MPU
regions #7 and #6, similar to Zephyr. Besides, Tizen supports

C OMMON P ITFALLS IN U SING MPU IN THE W ILD

9
10
11

void MPU_vTaskDelay(TickType_t xTicksToDelay){
BaseType_t xRunningPrivileged =xPortRaisePrivilege();vTaskDelay(xTicksToDelay);
vPortResetPrivilege(xRunningPrivileged);}
BaseType_t xPortRaisePrivilege(void){
BaseType_t xRunningPrivileged;
xRunningPrivileged = portIS_PRIVILEGED();/*If the CPU is not privileged, raise privilege.*/if (xRunningPrivileged == pdFALSE){
portRAISE_PRIVILEGE();

12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

}
return xRunningPrivileged;}#define portRAISE_PRIVILEGE() __asm volatile ("svc %0 \n"::"i" (portSVC_RAISE_PRIVILEGE) : "memory");
void prvSVCHandler(uint32_t* pulParam){...
case portSVC_RAISE_PRIVILEGE:
if ((ulPC >= _syscalls_flash_start_) && (ulPC <=_syscalls_flash_end_)){__asm {/*Obtain control value.*/
mrs ulReg, control/*Set privilege bit.*/bic ulReg, #1/*Write back control value*/msr control, ulReg}}
break;...
}

Listing 1.

Kernel wrapper in FreeRTOS-MPU

To verify our observation, we built a firmware with
FreeRTOS-MPU. It has a stack overflow bug in a task. By
exploiting it, we overwrote the return address on the stackwith the address of the function xPortRaisePrivilege.
As a result, the executing privilege was escalated. Combining
more sophisticated ROP programming, we were able to run
arbitrary code with elevated privilege. Since all other MPU
protections like TMI and KMI are based on the privilege
separation, any privilege escalation attack will render thesesecurity mechanisms useless.
On the other hand, some basic protections such as CIP,
DEP, and stack guard (SG) do not need to assign different
permissions for privileged and unprivileged modes. For example, RIoT sets the permission as non-executable for the whole
RAM and read-only for stack guard range regardless of theprivilege mode, and it runs the entire firmware under privileged
mode. However, MPU control registers (e.g., MPU_CTRL)
are located in the system peripheral region, which can beaccessed by any privileged code. Even worse, systems often
provide easy-to-use driver APIs for MPU configurations (e.g.,
mpu_enable and mpu_disable in RIoT). This means
once an attacker is able to carry out a control flow hijacking
attack, they can directly invoke these functions to completely
disable MPU protections.
B. Incomplete Protection
As shown in Table I, only a few MCU OSs support MPUenabled security features, among which many are default-off.
Furthermore, due to the hardware limitation of MPU, we foundexisting protections are too coarse-grained to be really usefulin real world.
First, most systems only focus on memory protection andstandard peripherals are not protected by default. Although
there may be a few remaining MPU regions that can be
configured individually by each user mode task, they are notvery suitable for protecting small peripheral regions scatteredin the address space due to the alignment problem and thelimited number of MPU regions, as mentioned in Section II.
For instance, the memory range for the Audio peripheral on
MPS2+ FPGA prototyping system broad (Cortex-M4 AN386)
is 0x40024000-0x40024FFF (16 Bytes).

Second, developers have the real-world need to assign
separate access rights to interrupt handlers [29]. However,this is very challenging since ARM Nested Vector Interrupt
Controller (NVIC) registers for interrupt line configurations
are located in the system peripheral region, which can only beaccessed in privileged mode.
Furthermore, although the memory regions that are notcovered by MPU regions only allows privileged access, it enables all access permissions including read, write, and execute,which also has potential hazards. Assuming that an attacker
exploits a stack overflow in a task stack, they cannot executethe malicious code in its stack due to MPU stack isolation.
However, they can put malicious code in these un-mapped
regions beforehand, and use a stack overflow attack to redirect
the control flow to malicious code in these regions.
MPUs cannot resist hardware attacks. For example, they
do not restrict peripherals as master, allowing them to accessall memory (e.g., via DMA). If the attacker is able to establish
access via JTAG or in the case of micro-probing, MPU cannot
help at all.
C. High Overhead
We also found leveraging MPU to realize kernel or task
memory isolation (KMI and TMI) incurs too much overheadin many real-world application scenarios. This is because
each invocation to kernel API has to go through a full privilege mode switch. Since kernel APIs are frequently invoked,
this poses a significant impact on real-time performance.
Our experiment shows that one thousand privilege switch of
FreeRTOS-MPU system takes 3.5ms in average on MPS2+FPGA prototyping system broad (Cortex-M4 AN386) with
25MHZ CPU clock frequency. In a previous research [31],a similar result was obtained. Such high overhead rules out
MPU’s application in many scenarios having strict real-time
constraints [31].
To realize TMI, the MPU regions need to be re-configured
for different tasks and applications. For example, Tizen has toreset MPU regions #3-7 during the application switch and #6
and #7 during the task switch, which will also cause delays.
D. Conflicting with Existing System Design
To integrate MPU-based protection, some existing mechanisms have to be re-designed or even become incompatible.
For example, user mode tasks of FreeRTOS-MPU cannot use
dynamic queues because there is no shared memory between
any two tasks as we mentioned in Section III. To overcome
this, a task has to allocate memory statically and shares it withthe peers by configuring an MPU region. Note that each peer
needs the same MPU region for each queue. This applies tosemaphores too, which is a special kind of queue (queue lengthis one). If a task needs multiple queues/semaphores or antheradditional memory regions (e.g., a task may also need to write
USB data to a DMA-mapped buffer in RAM), MPU resources
would soon become exhausted. Similarly, Zephyr and Tizen
also suffer from the same issue.
E. Fragmented Programming Interface
Other than the standard MPU offered by ARM, chip
vendors tend to design proprietary MPUs to distinguish themfrom others. The customized MPUs—while mostly providing
better security guarantees—impose a steep learning curve fordevelopers and may discourage them from adopting MPUs oreven lead to programming errors. For example, many of NXP’s
Kinetis series MCUs discard ARM MPU and integrate NXP’s
proprietary MPU called sysMPU, Compared to ARM MPUs
which can only restrict the permission of CPU, sysMPU can
restrict the permission of every memory reference generated
by each bus master including peripherals. However, in our experiments, when sysMPU is enabled, by default, all peripherals
cannot directly access RAM (i.e., via DMA) and this causes
firmware hangs in many cases. To properly use it, developers
have to correctly configure sysMPU, which requires a deep
knowledge of sysMPU design. More likely, when developers
face difficulties, they may simply give up and disable sysMPU
as we have witnessed in many NXP demos.
Summary: IoT devices are low-cost energy-efficient devices.
If more transistors are reserved for complex hardware security
features, not only the price of SoC could be raised accordingly, but also increased power consumption rules out many
applications in which thermal design power (TDP) concerns.
Due to the reasons discussed earlier and many complaints
we found in developer forums (e.g., [30]), only 30% of
manufacturers implement one or more MCU security featuresin their products [1].

separately. There is a waste of 3KB and 1KB of memory spacecorrespondingly. With sub-regions, the same 8KB region canbe shared between the two tasks. Specifically, when runningtask one, MPU is configured so that the highest three subregions of the 8KB region are disabled. When running task
two, MPU is configured so that the lowest two sub-regions of
the 8KB region are disabled. In this way, the 8KB memory
block is reused by the two tasks without wasting any memory.
The default ARMv7-M address map [25] defines the default
memory access permissions and attributes of memory regions
when MPU is not present. Therefore, it can be used to reduce
MPU region consumption. Specifically, the IACCVIOL fieldof Memory Management Fault Status Register (MMFSR) indicates whether an Execute Never (XN) fault has been triggered
when memory access violates the permissions of the default
memory map (e.g., non-executable for standard and systemperipheral regions). If we can leverage this feature to set XN,
an MPU region can be saved.
Compiler-based approaches can intelligently figure out an
optimized MPU configuration for certain tasks [31], [28].
For example, MINION [31] uses k-means clustering to groupmemory sections having similar access permissions together
to minimize the number of required MPU regions.
C. New Hardware FeaturesV.

S UGGESTIONS

A. Minimizing Pitfalls
Developers can raise the bar to bypass MPU protections for attacker by following the suggestions below. As isdemonstrated in Section IV-A, inappropriate implementation ofsystem calls can be leveraged by attackers to break KMI. Thus,
developers should pay more attention to functions involvedin privilege escalations like system calls. To be specific,
additional caller checks should be performed before systemcall invocations, and the kernel should make sure the privilege
is dropped after system calls. Besides, some MPU-enable
OSs just run the whole system at the privileged mode like
RIoT. Therefore, a single vulnerability could grant attacker
the capability to reconfigure MPUs, thereby disabling thedesired security features. We recommend to drop privilege
immediately after MPU configuration.
The ARMv7 architecture allows MPU regions to overlap,
and higher-numbered regions always have precedence. Thus,
during a task switching, in addition to re-configuring the MPU
regions, system should make sure that unused MPU regions are
disabled. It can prevent leaking permission from the previous
task to the next one.
B. Region Usage Optimization
A limitation with MPU is that only a few number ofregions are supported (e.g., only eight regions for CortexM0+/M3/M4). Creatively using the sub-region disable field(SRD) of BASR can overcome this limitation to some extent.
As mentioned in Section II, each memory region can bedivided into eight sub-regions, which can be enabled/disabledindividually. Suppose a developer needs to allocate a 5KB
region and a 3KB region for two tasks. Without sub-regions,the developer has to configure two regions of 8KB and 4KB

Although ARMv8-M provides a more powerful MPU design, it cannot solve all the problems. In the long term, we
expect a redesigned architecture that fundamentally addresses
the illustrated insecurity and inflexibility in a lightweightway. Along this direction, hardware-based solutions havebeen proposed [32], [33]. The most representative work is
TrustLite[32]. It is a radical hardware redesign that efficiently
implements many novel security primitives (e.g., executionaware MPU, secure loader) for embedded devices. In addition, the ARMv8-M architecture has extended TrustZone
technology to Cortex-M series processors, allowing for TEE
to be deployed in MCUs. For example, Mbed OS already
implemented PSA which provides the root-of-trust service andinfrastructure for developing secure IoT applications.
VI.

C ONCLUSION

In this work, we investigate the MPU usage of popularcyber-physical systems in the wild. To our surprise, we foundthat MPU as a ready-to-use security feature for protecting
microcontroller is rarely used in real-world products. We
studied the source code of MCU OSs in an attempt to findexplanations for this situation and eventually identified four
reasons. Unfortunately, some of them are fundamental and not
remedial in a short term. We give recommendations for betteruse of MPU and hope our findings can inspire research on
novel usage of MPU and new hardware retrofitting for MCUs.
ACKNOWLEDGMENT
We thank all the anonymous reviewers for theirconstructive comments. This work is supported by the
National Natural Science Foundation of China (Grant
No.62202188), The National Key R&D Program of China(Grant No.2022YFB31033400), and Cisco Research.

R EFERENCES
[1]

[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]

[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]

[26]
[27]
[28]

[29]
[30]

[31]

[32]
[33]

[34]

“2019 Embedded Markets Study,” https://www.embedded.com/wp-c
ontent/uploads/2019/11/EETimes_Embedded_2019_Embedded_Markets_Study.pdf, 2019.
“Apache Mynewt,” https://github.com/apache/mynewt-core, 2020.
“FreeRTOS AWS Reference Integrations,” https://github.com/aws/ama
zon-freertos, 2020.
“Memory management unit,” https://en.wikipedia.org/wiki/Memory_m
anagement_unit, 2020.
“TinyOS,” https://github.com/tinyos/tinyos-main, 2020.
“CMSIS-Zone,” https://www.keil.com/pack/doc/CMSIS/Zone/html/in
dex.html, 2021.
“FreeRTOS: Memory Protection Unit (MPU) Support,” https://www.fr
eertos.org/FreeRTOS-MPU-memory-protection-unit.html, 2021.
“FreeRTOS: Real-time operating system for microcontrollers,” https://www.freertos.org/, 2021.
“Mbed: Rapid IoT device development,” https://os.mbed.com/, 2021.
“Azure RTOS ThreadX,” https://github.com/azure-rtos/threadx, 2022.
“Contiki: The Open Source Operating System for the Internet ofThings,” http://www.contiki-os.org/, 2022.
“Device OS,” https://docs.particle.io/getting-started/device-os/introduction-to-device-os/, 2022.
“embOS-MPU—
Comprehensive
memoryprotection,”
https://www.segger.com/products/rtos/embos/editions/embos-mpu/e
mbos-mpu-basic-concepts/, 2022.
“embOS – The Leading RTOS (Real Time Operating System),” https://www.segger.com/products/rtos/embos/, 2022.
“Huawei LiteOS,” https://github.com/LiteOS/LiteOS, 2022.
“Micrium OS,” https://www.silabs.com/developers/micrium-os, 2022.
“Mongoose OS,” https://mongoose-os.com/, 2022.
“MQX Software Solutions,” https://www.nxp.com/design/software/em
bedded-software/mqx-software-solutions:MQX_HOME, 2022.
“Nucleus RTOS,” https://www.mentor.com/embedded-software/nucleu
s/, 2022.
“OpenWrt,” https://openwrt.org/start, 2022.
“RIoT,” https://github.com/RIOT-OS/RIOT, 2022.
“RT-Thread,” https://www.rt-thread.org/, 2022.
“SAFERTOS CORE Overview,” https://www.highintegritysystems.com/safertos-core/, 2022.
“Samsung TizenRT,” https://github.com/Samsung/TizenRT, 2022.
“System address map,” https://developer.arm.com/documentation/dd
i0489/c/programmers-model/system-address-map, 2022, last accessed:
2022-05-01.
“VXWORKS,” https://www.windriver.com/products/vxworks/, 2022.
“Zephyr Project,” https://docs.zephyrproject.org/latest/introduction/ind
ex.html, 2022.
A. A. Clements, N. S. Almakhdhub, S. Bagchi, and M. Payer, “ACES:
Automatic Compartments for Embedded Systems,” in 27th USENIX
Security, 2018.
N. Community, “MPU advanced features?” https://community.nxp.com/message/1144517?commentID=1144517#comment-1144517, 2019.
S. Community, “FAQ: Ethernet not working on STM32H7x3,”
https://community.st.com/s/article/FAQ-Ethernet-not-working-on-STM
32H7x3, 2018.
C. H. Kim, T. Kim, H. Choi, Z. Gu, B. Lee, X. Zhang, and D. Xu, “Securing real-time microcontroller systems through customized memory
view switching,” in NDSS, 2018.
P. Koeberl, S. Schulz, A.-R. Sadeghi, and V. Varadharajan, “Trustlite:
A security architecture for tiny embedded devices,” in EuroSys, 2014.
T. Nyman, J.-E. Ekberg, L. Davi, and N. Asokan, “CFI CaRE:
Hardware-Supported Call and Return Enforcement for Commercial
Microcontrollers,” in RAID. Springer, 2017.
Slashdot., “Best Real-Time Operating Systems (RTOS) of 2023,” https://slashdot.org/software/iot-operating-systems/, 2023.

[35]

Wikipedia, “Executable space protection,” https://en.wikipedia.org/wik
i/Executable_space_protection#Windows, 2022, last accessed: 2023-0201.
[36] Wikipedia, “Process isolation,” https://en.wikipedia.org/wiki/Process_isolation, 2022, last accessed: 2023-02-01.
[37] Wikipedia, “User space and kernel space,” https://en.wikipedia.org/w
iki/User_space_and_kernel_space, 2022, last accessed: 2023-02-01.
[38] Wikipedia, “WˆX,” https://en.wikipedia.org/wiki/W%5EX, 2022, lastaccessed: 2023-02-01.

A PPENDIX
We detail more case studies of MPU usage in open-source
IoT OSs (summarized in Table I) as follows.
A. Case Study: Keil RTX
Keil RTX can leverage CMSIS-Zone [6] to isolate tasks andperipherals from each other (i.e., TMI and PI are supported).
An important concept in RTX is execution zone, in which users
can configure the access permissions (i.e., readable, writable,
and executable) to a bundle of memory regions and peripherals(i.e., CIP and DEP are also supported). This ensures thateven if a task stack is corrupted, the error cannot tamper withthe data and peripherals of other tasks. However, Keil RTX
does not offer isolation of normal user tasks and the kernel(i.e., KMI is unsupported), so that code and data of the kernel
cannot be entirely opaque to user tasks.
B. Case Study: Azure RTOS ThreadX
Similar to Tizen, ThreadX is able to dynamically load
modules, and each module includes several tasks and canbe configured as an isolated part with others. However, theisolation is only implemented at the module level, not the task
isolation. Therefore, TMI, PI and CSG are unsupported.