Zephyr User Mode: Explained in Simple Words
Many embedded developers come from bare-metal or traditional RTOS backgrounds where everything runs with full privileges. When they first encounter Zephyr’s user mode, the idea of separating code into privileged and unprivileged domains can feel unnecessary or overly complex. But as embedded systems grow more connected, and as regulations like the Cyber Resilience Act (CRA) push for stronger security and fault isolation, user mode becomes an essential tool rather than an optional feature.
In this presentation, we explain Zephyr’s user mode in simple, practical terms. We start with the core motivations: how privilege separation improves safety, contains faults, and supports modern security expectations. Then we walk through the key concepts, APIs, and mechanisms that make user mode work, translating them into everyday language and relatable examples.
Based on real-world training experience, we highlight the initial hurdles developers face and show how quickly user mode becomes intuitive once you understand what problems it solves. Finally, we demonstrate how to structure applications using user mode and assign permissions. By the end, attendees will not only grasp what user mode does, but also why it matters today and how to use it effectively in their own projects.
What this presentation is about and why it matters
How do you keep one buggy or untrusted component from putting an entire Zephyr system at risk? Roy Jamil walks through Zephyr user mode as a practical answer to that tension, using the language of threads, memory protection, domains, syscalls, and kernel objects. The talk is anchored in Zephyr RTOS on ARM microcontrollers, with examples that show what changes when user space is enabled and how access gets shaped in code and at build time. It is a good fit for people who want a clearer mental model of isolation in embedded systems and the real cost of enforcing it.
Who will benefit the most from this presentation
- Embedded firmware engineers working in Zephyr who need to separate trusted and untrusted code paths
- RTOS developers on ARM Cortex-M hardware who are starting to use MPU-backed protection
- System architects designing multi-component products where fault isolation matters
- Security-minded embedded engineers evaluating the cost of adding user space
- Developers maintaining code that uses syscalls, kernel objects, or memory domains in Zephyr
What you need to know
A working familiarity with Zephyr basics will help, especially threads and kernel services. The talk also assumes some comfort with embedded memory protection concepts.
- Basic understanding of Zephyr RTOS threading
- Awareness of supervisor versus user execution contexts
- Familiarity with ARM microcontrollers and the MPU
- Some exposure to kernel objects such as semaphores or mutexes
Glossary (terms used in this talk)
- RTOS (Real-Time Operating System): An operating system designed to provide predictable timing behavior for real-time applications.
- MPU (Memory Protection Unit): A hardware unit that enforces memory access rules and helps isolate software components.
- syscall (System Call): A controlled entry point from unprivileged code into privileged kernel functionality. It is used to request services that cannot be performed directly from restricted execution mode.
- memory domain: A set of memory partitions associated with a group of threads. It defines what memory those threads can read or write, helping isolate components from one another.
- memory partition: A contiguous region of memory that can be assigned to one or more domains. Partitions are the building blocks used to express shared or isolated access to memory.
- kernel object: A protected operating-system resource that is accessed through the kernel rather than directly. Typical examples include synchronization and communication primitives, and device interfaces.
- user mode: A restricted processor execution mode where threads run with limited privileges, cannot execute privileged instructions directly, and must use controlled interfaces such as syscalls to access kernel services or hardware.
- supervisor mode (kernel mode): Privileged execution mode used by the kernel where code has full access to memory and hardware and can execute privileged instructions; kernel threads run in this mode.
Toolbox (mentioned in this talk)
- Zephyr RTOS: A scalable real-time operating system for connected and resource-constrained devices. It often owns much of the system startup flow, including hardware initialization and thread setup.
- Visual Studio Code: A lightweight source code editor with broad language support and extension-based integration. It is often used for embedded development and can pair well with containerized workflows.
- ARM: A family of processor architectures commonly used in embedded systems and mobile devices.
- CMake: A cross-platform build system generator that helps define and drive builds across different compilers, IDEs, and platforms.
- Workbench for Zephyr: A Visual Studio Code extension for working with Zephyr-based projects. It provides an IDE-focused workflow around Zephyr development.
- NXP Freedom MCXN: A development board family used for embedded evaluation and benchmarking on NXP MCX microcontrollers. It provides a concrete target for measuring RTOS behavior and system overheads.
Final thoughts
Practical and explanatory, this talk gives you a cleaner vocabulary for thinking about isolation in Zephyr, plus a useful way to reason about where protection boundaries live and what they cost. It will help firmware engineers, RTOS users, and architects who need to separate trusted code from the rest of the system. The value is not just in the APIs, it is in seeing how the pieces fit together when safety and structure start to matter.
This overview is AI-generated from the session transcript. Spot an issue? Let us know.
Thank you! Yes, the overhead is definitely quite high, though it’s worth mentioning that it only occurs at the moment of the operation itself. In practice, it should still be tolerable for most applications.
Thanks Roy. The presentation, to my understanding, covered a high level overview of RTOS application not just limited to Zephyr. From my C coding experience access restrictions between modules, either enforced or by agreement, are preferred. The understanding of the overheads to sys calls is very interesting - the cost in cycles of the RTOS vs the protection gained.
Thanks! That was exactly the goal, and Zephyr makes MPU-based user mode particularly simple to apply on MCUs. And agreed, the cycles-vs-protection tradeoff is where the real engineering decision lives.
Can you make your slides available? Thanks.
Yes, I've added the slides








Very nice presentation Roy. I particularly liked the annotations you made on each slide. Very effective in helping viewers follow along. Thanks again for a job well done. I have a much clearer understanding now of how user mode is setup in Zephyr. The added overhead to syscalls was more than I expected, so it was nice you included that.