Overview
Threat Model
User mode threads are considered to be untrusted by Zephyr and are therefore isolated from other user mode threads and from the kernel. A flawed or malicious user mode thread cannot leak or modify the private data/resources of another thread or the kernel, and cannot interfere with or control another user mode thread or the kernel.
Example use-cases of Zephyr’s user mode features:
The kernel can protect against many unintentional programming errors which could otherwise silently or spectacularly corrupt the system.
The kernel can sandbox complex data parsers such as interpreters, network protocols, and filesystems such that malicious third-party code or data cannot compromise the kernel or other threads.
The kernel can support the notion of multiple logical “applications”, each with their own group of threads and private data structures, which are isolated from each other if one crashes or is otherwise compromised.
Design Goals
For threads running in a non-privileged CPU state (hereafter referred to as ‘user mode’) we aim to protect against the following:
We prevent access to memory not specifically granted, or incorrect access to memory that has an incompatible policy, such as attempting to write to a read-only area.
Access to thread stack buffers will be controlled with a policy which partially depends on the underlying memory protection hardware.
A user thread will by default have read/write access to its own stack buffer.
A user thread will never by default have access to user thread stacks that are not members of the same memory domain.
A user thread will never by default have access to thread stacks owned by a supervisor thread, or thread stacks used to handle system call privilege elevations, interrupts, or CPU exceptions.
A user thread may have read/write access to the stacks of other user threads in the same memory domain, depending on hardware.
On MPU systems, threads may only access their own stack buffer.
On MMU systems, threads may access any user thread stack in the same memory domain. Portable code should not assume this.
By default, program text and read-only data are accessible to all threads on read-only basis, kernel-wide. This policy may be adjusted.
User threads by default are not granted default access to any memory except what is noted above.
We prevent use of device drivers or kernel objects not specifically granted, with the permission granularity on a per object or per driver instance basis.
We validate kernel or driver API calls with incorrect parameters that would otherwise cause a crash or corruption of data structures private to the kernel. This includes:
Using the wrong kernel object type.
Using parameters outside of proper bounds or with nonsensical values.
Passing memory buffers that the calling thread does not have sufficient access to read or write, depending on the semantics of the API.
Use of kernel objects that are not in a proper initialization state.
We ensure the detection and safe handling of user mode stack overflows.
We prevent invoking system calls to functions excluded by the kernel configuration.
We prevent disabling of or tampering with kernel-defined and hardware-enforced memory protections.
We prevent re-entry from user to supervisor mode except through the kernel-defined system calls and interrupt handlers.
We prevent the introduction of new executable code by user mode threads, except to the extent to which this is supported by kernel system calls.
We are specifically not protecting against the following attacks:
The kernel itself, and any threads that are executing in supervisor mode, are assumed to be trusted.
The toolchain and any supplemental programs used by the build system are assumed to be trusted.
The kernel build is assumed to be trusted. There is considerable build-time logic for creating the tables of valid kernel objects, defining system calls, and configuring interrupts. The .elf binary files that are worked with during this process are all assumed to be trusted code.
We can’t protect against mistakes made in memory domain configuration done in kernel mode that exposes private kernel data structures to a user thread. RAM for kernel objects should always be configured as supervisor-only.
It is possible to make top-level declarations of user mode threads and assign them permissions to kernel objects. In general, all C and header files that are part of the kernel build producing zephyr.elf are assumed to be trusted.
We do not protect against denial of service attacks through thread CPU starvation. Zephyr has no thread priority aging and a user thread of a particular priority can starve all threads of lower priority, and also other threads of the same priority if time-slicing is not enabled.
There are build-time defined limits on how many threads can be active simultaneously, after which creation of new user threads will fail.
Stack overflows for threads running in supervisor mode may be caught, but the integrity of the system cannot be guaranteed.
High-level Policy Details
Broadly speaking, we accomplish these thread-level memory protection goals through the following mechanisms:
Any user thread will only have access to a subset of memory: typically its stack, program text, read-only data, and any partitions configured in the Memory Protection Design it belongs to. Access to any other RAM must be done on the thread’s behalf through system calls, or specifically granted by a supervisor thread using the memory domain APIs. Newly created threads inherit the memory domain configuration of the parent. Threads may communicate with each other by having shared membership of the same memory domains, or via kernel objects such as semaphores and pipes.
User threads cannot directly access memory belonging to kernel objects. Although pointers to kernel objects are used to reference them, actual manipulation of kernel objects is done through system call interfaces. Device drivers and threads stacks are also considered kernel objects. This ensures that any data inside a kernel object that is private to the kernel cannot be tampered with.
User threads by default have no permission to access any kernel object or driver other than their own thread object. Such access must be granted by another thread that is either in supervisor mode or has permission on both the receiving thread object and the kernel object being granted access to. The creation of new threads has an option to automatically inherit permissions of all kernel objects granted to the parent, except the parent thread itself.
For performance and footprint reasons Zephyr normally does little or no parameter error checking for kernel object or device driver APIs. Access from user mode through system calls involves an extra layer of handler functions, which are expected to rigorously validate access permissions and type of the object, check the validity of other parameters through bounds checking or other means, and verify proper read/write access to any memory buffers involved.
Thread stacks are defined in such a way that exceeding the specified stack space will generate a hardware fault. The way this is done specifically varies per architecture.
Constraints
All kernel objects, thread stacks, and device driver instances must be defined at build time if they are to be used from user mode. Dynamic use-cases for kernel objects will need to go through pre-defined pools of available objects.
There are some constraints if additional application binary data is loaded for execution after the kernel starts:
Loaded object code will not be able to define any kernel objects that will be recognized by the kernel. This code will instead need to use APIs for requesting kernel objects from pools.
Similarly, since the loaded object code will not be part of the kernel build process, this code will not be able to install interrupt handlers, instantiate device drivers, or define system calls, regardless of what mode it runs in.
Loaded object code that does not come from a verified source should always be entered with the CPU already in user mode.