REVIEW 4 major objections 5 minor 8 references
Good Motive but Bad Design: Why ARM MPU Has Become an Outcast in Embedded Systems
T0 review · 4 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash
Pith's one-line read The paper claims ARM's MPU, meant to protect embedded devices, is trivially bypassed and slows real-time tasks, so products avoid it for good reason.
desk verdict Useful FreeRTOS MPU case study, but the broader claim that ARM MPU provides virtually no security enhancement is not supported by the evidence. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The mechanism that carries the argument is ARMv7-M's MPU: a small set of hardware regions defined by base-address and size registers, requiring power-of-two aligned regions (minimum 32 bytes) and offering only eight regions on common Cortex-M parts, with the FreeRTOS port mapping kernel code, kernel data, peripherals, and per-task stacks into those regions. The decisive element is the syscall path: because kernel APIs live in a privileged-only region, FreeRTOS exposes xPortRaisePrivilege and vPortResetPrivilege as callable functions, and the paper shows how this single exposed function annihilates the isolation boundary; the same path also produces the per-call privilege-switch overhead that the paper measures.
What would settle it
A concrete falsifier would be a functioning ARM MPU port that lets user tasks invoke kernel services only through a hardware-enforced, validated trap (for example, an SVC handler with no callable privilege-raising stub) and that still provably defends against a control-flow hijack attempt like the paper's stack-overflow exploit; if such a port retains real-time deadlines, the paper's claim that these pitfalls are fundamental to MPU would be directly contradicted.
Extended reading notes
Core claim
The central claim is that MPU-enabled FreeRTOS provides no real security benefit: a control-flow hijack on a user task can simply jump to the embedded function xPortRaisePrivilege, permanently elevate privilege, and access all device memory. This is not a missing patch but a structural flaw, because the privilege-raising entry point must exist in firmware for kernel API calls, and its address can always be found by reverse engineering. Meanwhile, the same design forces a privilege switch on every kernel API invocation and MPU reconfiguration on every task switch, costing several milliseconds per thousand switches in their 25 MHz test setup and missing real-time deadlines. The paper concludes that ARMv8-M's larger, more flexible MPU mitigates but does not solve these drawbacks, and that safer embedded systems need either better software workarounds or a hardware redesign.
Load-bearing premise
The paper's argument assumes the flaws it found in FreeRTOS's MPU port come from the MPU hardware itself, not from FreeRTOS's choice of exposing xPortRaisePrivilege, so that every MPU-based RTOS would suffer the same security and performance failures.
Editorial extensions
If this is right
- If the paper is right, existing ARMv7-M MPU ports of major RTOSs should not be treated as a meaningful security boundary; products relying on them should assume a single memory-corruption bug leads to full privilege compromise.
- The measurements imply that real-time applications with tight deadlines cannot absorb the privilege-switch and MPU-reconfiguration overhead, so MPU-enabled kernels will stay off projects where latency matters unless the switch cost is eliminated.
- The analysis suggests ARMv8-M's improvements (16 regions, start-and-limit addressing) reduce configuration pain but leave the privilege-escalation path and per-call switching unchanged, so the security-adoption problem will persist on newer chips.
- The paper's sub-region trick shows a low-cost way to stretch scarce MPU regions by sharing one aligned block among tasks with disjoint sub-regions, which is directly useful even before hardware changes arrive.
Reading between the lines
- My inference: beyond the paper's FreeRTOS case, the same exposed-syscall flaw should be expected in any MPU port that lets user code transition to privileged mode through a callable stub rather than a hardware-enforced trap; routing all kernel entry through an unprivileged SVC exception with strict validation would likely close the bypass the paper found, but that design is not tested in the paper
- My inference: a direct testable extension would be to build the same MPU-enabled kernel with all kernel entry through an SVC doorbell and measure whether the security bypass closes while the overhead stays acceptable; if both happen, the paper's 'fundamental design' conclusion would be narrowed to a syscall-design problem.
- My inference: the paper's peripheral-protection gap points to a complementary software idea: concentrating all sensitive I/O behind a single privileged 'gateway' task, so the three spare MPU regions protect only that gateway's mailbox rather than trying to cover many tiny peripheral registers individually.
Signed reviews
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper investigates why the ARM memory protection unit (MPU) is rarely adopted in real embedded products, using the MPU-enabled port of FreeRTOS as a case study. It surveys RTOS-level MPU support, describes the FreeRTOS MPU memory map and privilege model, and reports four pitfalls: a privilege-escalation entry point (xPortRaisePrivilege) that can be reused by a control-flow hijacking attack, conflicts with existing system mechanisms such as dynamic queues and interrupt handlers, coarse-grained and inflexible region protection, and measured overhead from repeated privilege switches. The paper concludes that these pitfalls are fundamental drawbacks of the ARM MPU and that the MPU provides "virtually no security enhancement" while decreasing performance and responsiveness.
Significance. The paper is a useful case study of a real MPU-enabled RTOS. Its concrete demonstration of privilege escalation through the exposed xPortRaisePrivilege routine is a valid and reproducible observation, and the overhead measurement quantifies the cost of FreeRTOS's specific privilege-switch pattern. The adoption table and the discussion of MPU region limitations are also informative. However, the broader conclusion is not supported by the evidence: the main vulnerability is an implementation/API design choice in FreeRTOS rather than a property forced by the ARM MPU, and no baseline comparison against non-MPU FreeRTOS is provided for the security claim. With reframing or additional evidence, this could become a solid case study, but the headline claim currently overreaches.
major comments (4)
- [Section 7] The inference from FreeRTOS to all ARM MPU designs is load-bearing but unsupported. The sentence "the demonstrated pitfalls root in the fundamental design drawbacks of MPU" ignores that the privilege-escalation pitfall is caused by exposing xPortRaisePrivilege as a reachable API; nothing in ARMv7-M MPU forces an RTOS to provide such a routine, and an SVC-based syscall gate or the MPU-reconfiguration approach of MINION (Section 6.2) avoids it. At minimum, the paper must either test a differently designed MPU RTOS or restrict the conclusion to the FreeRTOS MPU port.
- [Abstract and Section 4] The claim that MPU brings "virtually no security enhancement" is not supported because there is no baseline comparison with non-MPU FreeRTOS. Under the demonstrated attack, the attacker still needs a memory-corruption primitive and a ROP chain through xPortRaisePrivilege; on non-MPU FreeRTOS the same corruption would directly yield arbitrary code execution with full privileges. That difference is a security enhancement, even if incomplete. The threat model and a comparison of exploitation effort are needed before this claim can stand.
- [Section 4, Increased Overhead] The overhead conclusion is not quantified against a baseline. The 3.5 ms per 1000 privilege switches on a 25 MHz MPS2+ measures FreeRTOS's specific privilege-switch pattern and does not separate privilege-switch cost from MPU reconfiguration cost, nor does it compare with ordinary kernel API call overhead or with an alternative MPU design such as MINION's memory-view switching. Without this, the paper cannot conclude that the overhead "rules out the MPU in many real-time applications."
- [Section 1 and Table 1] The adoption claim that "real devices rarely use MPU-enabled variants" is supported only by the AWS example. Table 1 lists ARM Mbed and Nucleus as mandatory MPU support, but the paper never explains why these mandatory-support products do not contradict the "outcast" narrative. Either provide evidence of product-level adoption or label the claim as preliminary.
minor comments (5)
- [Throughout] There are numerous typographical errors, including "misc reants" in the abstract, "our our investigation" in Section 2, "MPU-eabled" in Section 5, "Exiting" in the Section 4 heading, "one the other hand" in Section 6.2, and "developingnew" in Section 5. A careful proofreading pass is needed.
- [Section 5] The sentence "IoT applications are becoming more and more" is incomplete and should be finished or removed.
- [Table 2] The memory map table is hard to parse: region 0 is described as a 2 GB code segment starting at 0x0 and region 3 as a 2 GB standard-peripheral region starting at 0x40000000, yet the overlap and precedence rules are not discussed. Please clarify the intended region layout and how the default region rules interact with these entries.
- [Listing 1 and Section 4] The listing is labeled as "pvPortMalloc function" but the function shown is MPU_pvPortMalloc, and the text refers to it by both names. Also, "xPortRaisePrivilege" is misspelled as "xPortRaisePrivilege" earlier in the same section; please use consistent naming.
- [References] Reference [7] is cited for the verified exploit but is described only as "A WS IoT Developer Guide," which is insufficient for a reader to locate the underlying technical report or talk. Please provide a complete citation or replace it with the original source.
Circularity Check
No circular reasoning found: the paper's empirical measurements and independent citations support its claims, and its overgeneralization from FreeRTOS to ARM MPU is a validity concern, not a circular one.
full rationale
The paper does not define its conclusions into its premises. Its key empirical claims are measured rather than derived from the conclusion: the privilege-switch overhead (3.5 ms per 1000 switches on MPS2+) is an observed benchmark, and the bypass of FreeRTOS's MPU protection is a demonstrated exploit against the xPortRaisePrivilege entry point, verified in the paper's experiments and by an independent Shmoocon talk. The only potentially questionable step is Section 7's generalization from MPU-enabled FreeRTOS to 'fundamental design drawbacks of MPU,' but that is a scope/evidence inference, not a circular one: it does not assume the conclusion, and it is not justified by the authors' own prior work. The paper cites external independent sources for its corroborating observations (MINION, TrustLite, CFI CaRE, ACES, and community reports) rather than relying on a self-citation chain. There are no fitted parameters renamed as predictions, no self-referential definitions, and no uniqueness theorem imported from the authors' own publications. Therefore the derivation chain is not circular; concerns about whether one RTOS port can bear the weight of the general conclusion belong to correctness and external validity, not circularity.
Assumptions & free parameters
assumptions (4)
- domain assumption ARMv7-M MPU hardware semantics (region count, alignment, sub-regions, default region) are correctly described and apply to the target board.
- domain assumption FreeRTOS MPU-enabled version implements the memory map and task privilege model described in Table 2.
- domain assumption A memory error such as a stack overflow can be turned into control-flow hijacking in a user-mode task.
- ad hoc to paper The pitfalls observed in FreeRTOS MPU are rooted in fundamental drawbacks of ARM MPU, not in FreeRTOS-specific implementation choices.
Cite this review
Pith. "Pith review of Good Motive but Bad Design: Why ARM MPU Has Become an Outcast in Embedded Systems." pith.science (2026). https://pith.science/paper/FNPEQRKS
@misc{pith2026190803638,
author = {Pith},
title = {Pith review of: Good Motive but Bad Design: Why ARM MPU Has Become an Outcast in Embedded Systems},
year = {2026},
howpublished = {\url{https://pith.science/paper/FNPEQRKS}},
note = {Machine review of arXiv:1908.03638}
}
read the original abstract
As more and more embedded devices are connected to the Internet, leading to the emergence of Internet-of-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 devices, has the potential to become a free lunch for the defenders. To our surprise, the MPU is seldom used by real-world products. The reasons are multi-fold. While there are non-technical reasons such as compatibility issues, more importantly, we found that MPU brings virtually no security enhancement at the expense of decreased performance and responsiveness. In this work, we investigate the MPU adoption in major real-time operating systems (RTOSs), in particular, the FreeRTOS, and try to pinpoint the fundamental reasons to explain why MPU is not favored. We hope our findings can inspire new remedial solutions to change the situation. We also review the latest MPU design and provide technical suggestions to build more secure embedded systems.
Reference graph
Works this paper leans on
-
[1]
Abraham A Clements, Naif Saleh Almakhdhub, Saurabh Bagc hi, and Mathias Payer. 2018. ACES: Automatic Compartments for Embedded Sys tems. In 27th USENIX Security
work page 2018
- [2]
-
[3]
ST Community. 2018. FAQ: Ethernet not working on STM32H7 x3. https://community.st.com/s/article/FAQ-Ethernet-not-working-on-STM32H7x3
work page 2018
-
[4]
Chung Hwan Kim, Taegyu Kim, Hongjun Choi, Zhongshu Gu, By oungyoung Lee, Xiangyu Zhang, and Dongyan Xu. 2018. Securing real-time mic rocontroller sys- tems through customized memory view switching. In NDSS
work page 2018
-
[5]
Patrick Koeberl, Steffen Schulz, Ahmad-Reza Sadeghi, an d Vijay Varadharajan
-
[6]
Thomas Nyman, Jan-Erik Ekberg, Lucas Davi, and N Asokan. 2017. CFI CaRE: Hardware-Supported Call and Return Enforcement for Commer cial Microcon- trollers. In RAID. Springer
work page 2017
-
[7]
Joel Sandin. 2016. A WS IoT Developer Guide. https://speakerdeck.com/jsandin/shmoocon-2016-explo iting-memory-corruption-vulnerabilities-on-the-free rtos-operating-system
work page 2016
-
[2014]
In EuroSys
TrustLite: A security architecture for tiny embedded devices. In EuroSys
Reviewed August 14, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.