573f32b6d2
Summary: revised attempt at addressing issue 6290. The
following provides an alternative to using
CONFIG_APPLICATION_MEMORY by compartmentalizing data into
Memory Domains. Dependent on MPU limitations, supports
compartmentalized Memory Domains for 1...N logical
applications. This is considered an initial attempt at
designing flexible compartmentalized Memory Domains for
multiple logical applications and, with the provided python
script and edited CMakeLists.txt, provides support for power
of 2 aligned MPU architectures.
Overview: The current patch uses qualifiers to group data into
subsections. The qualifier usage allows for dynamic subsection
creation and affords the developer a large amount of flexibility
in the grouping, naming, and size of the resulting partitions and
domains that are built on these subsections. By additional macro
calls, functions are created that help calculate the size,
address, and permissions for the subsections and enable the
developer to control application data in specified partitions and
memory domains.
Background: Initial attempts focused on creating a single
section in the linker script that then contained internally
grouped variables/data to allow MPU/MMU alignment and protection.
This did not provide additional functionality beyond
CONFIG_APPLICATION_MEMORY as we were unable to reliably group
data or determine their grouping via exported linker symbols.
Thus, the resulting decision was made to dynamically create
subsections using the current qualifier method. An attempt to
group the data by object file was tested, but found that this
broke applications such as ztest where two object files are
created: ztest and main. This also creates an issue of grouping
the two object files together in the same memory domain while
also allowing for compartmenting other data among threads.
Because it is not possible to know a) the name of the partition
and thus the symbol in the linker, b) the size of all the data
in the subsection, nor c) the overall number of partitions
created by the developer, it was not feasible to align the
subsections at compile time without using dynamically generated
linker script for MPU architectures requiring power of 2
alignment.
In order to provide support for MPU architectures that require a
power of 2 alignment, a python script is run at build prior to
when linker_priv_stacks.cmd is generated. This script scans the
built object files for all possible partitions and the names given
to them. It then generates a linker file (app_smem.ld) that is
included in the main linker.ld file. This app_smem.ld allows the
compiler and linker to then create each subsection and align to
the next power of 2.
Usage:
- Requires: app_memory/app_memdomain.h .
- _app_dmem(id) marks a variable to be placed into a data
section for memory partition id.
- _app_bmem(id) marks a variable to be placed into a bss
section for memory partition id.
- These are seen in the linker.map as "data_smem_id" and
"data_smem_idb".
- To create a k_mem_partition, call the macro
app_mem_partition(part0) where "part0" is the name then used to
refer to that partition. This macro only creates a function and
necessary data structures for the later "initialization".
- To create a memory domain for the partition, the macro
app_mem_domain(dom0) is called where "dom0" is the name then
used for the memory domain.
- To initialize the partition (effectively adding the partition
to a linked list), init_part_part0() is called. This is followed
by init_app_memory(), which walks all partitions in the linked
list and calculates the sizes for each partition.
- Once the partition is initialized, the domain can be
initialized with init_domain_dom0(part0) which initializes the
domain with partition part0.
- After the domain has been initialized, the current thread
can be added using add_thread_dom0(k_current_get()).
- The code used in ztests ans kernel/init has been added under
a conditional #ifdef to isolate the code from other tests.
The userspace test CMakeLists.txt file has commands to insert
the CONFIG_APP_SHARED_MEM definition into the required build
targets.
Example:
/* create partition at top of file outside functions */
app_mem_partition(part0);
/* create domain */
app_mem_domain(dom0);
_app_dmem(dom0) int var1;
_app_bmem(dom0) static volatile int var2;
int main()
{
init_part_part0();
init_app_memory();
init_domain_dom0(part0);
add_thread_dom0(k_current_get());
...
}
- If multiple partitions are being created, a variadic
preprocessor macro can be used as provided in
app_macro_support.h:
FOR_EACH(app_mem_partition, part0, part1, part2);
or, for multiple domains, similarly:
FOR_EACH(app_mem_domain, dom0, dom1);
Similarly, the init_part_* can also be used in the macro:
FOR_EACH(init_part, part0, part1, part2);
Testing:
- This has been successfully tested on qemu_x86 and the
ARM frdm_k64f board. It compiles and builds power of 2
aligned subsections for the linker script on the 96b_carbon
boards. These power of 2 alignments have been checked by
hand and are viewable in the zephyr.map file that is
produced during build. However, due to a shortage of
available MPU regions on the 96b_carbon board, we are unable
to test this.
- When run on the 96b_carbon board, the test suite will
enter execution, but each individaul test will fail due to
an MPU FAULT. This is expected as the required number of
MPU regions exceeds the number allowed due to the static
allocation. As the MPU driver does not detect this issue,
the fault occurs because the data being accessed has been
placed outside the active MPU region.
- This now compiles successfully for the ARC boards
em_starterkit_em7d and em_starterkit_em7d_v22. However,
as we lack ARC hardware to run this build on, we are unable
to test this build.
Current known issues:
1) While the script and edited CMakeLists.txt creates the
ability to align to the next power of 2, this does not
address the shortage of available MPU regions on certain
devices (e.g. 96b_carbon). In testing the APB and PPB
regions were commented out.
2) checkpatch.pl lists several issues regarding the
following:
a) Complex macros. The FOR_EACH macros as defined in
app_macro_support.h are listed as complex macros needing
parentheses. Adding parentheses breaks their
functionality, and we have otherwise been unable to
resolve the reported error.
b) __aligned() preferred. The _app_dmem_pad() and
_app_bmem_pad() macros give warnings that __aligned()
is preferred. Prior iterations had this implementation,
which resulted in errors due to "complex macros".
c) Trailing semicolon. The macro init_part(name) has
a trailing semicolon as the semicolon is needed for the
inlined macro call that is generated when this macro
expands.
Update: updated to alternative CONFIG_APPLCATION_MEMORY.
Added config option CONFIG_APP_SHARED_MEM to enable a new section
app_smem to contain the shared memory component. This commit
seperates the Kconfig definition from the definition used for the
conditional code. The change is in response to changes in the
way the build system treats definitions. The python script used
to generate a linker script for app_smem was also midified to
simplify the alignment directives. A default linker script
app_smem.ld was added to remove the conditional includes dependency
on CONFIG_APP_SHARED_MEM. By addining the default linker script
the prebuild stages link properly prior to the python script running
Signed-off-by: Joshua Domagalski <jedomag@tycho.nsa.gov>
Signed-off-by: Shawn Mosley <smmosle@tycho.nsa.gov>
194 lines
8.0 KiB
ReStructuredText
194 lines
8.0 KiB
ReStructuredText
.. _usermode:
|
|
|
|
User Mode
|
|
#########
|
|
|
|
This section describes access policies for kernel objects, how system calls
|
|
are defined, and how memory may be managed to support user mode threads.
|
|
|
|
For details on creating threads that run in user mode, please see
|
|
:ref:`lifecycle_v2`.
|
|
|
|
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.
|
|
|
|
- Threads are automatically granted access to their own stack memory
|
|
region, and all other stacks are inaccessible.
|
|
|
|
- By default, program text and read-only data are accessible to all threads
|
|
on read-only basis, kernel-wide. This policy may be adjusted.
|
|
|
|
- If the optional "application memory" feature is enabled, then all
|
|
non-kernel globals defined in the application and libraries will be
|
|
accessible.
|
|
|
|
- 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 its own stack memory by default.
|
|
Access to any other RAM will need to be done on the thread's behalf through
|
|
system calls, or specifically granted by a supervisor thread using the
|
|
:ref:`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.
|
|
|
|
- If the optional :option:`CONFIG_APPLICATION_MEMORY` feature is enabled, all
|
|
threads will have read/write access to non-kernel globals.
|
|
|
|
- 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.
|
|
|
|
|
|
.. toctree::
|
|
:maxdepth: 2
|
|
|
|
kernelobjects.rst
|
|
syscalls.rst
|
|
memory_domain.rst
|
|
mpu_stack_objects.rst
|
|
mpu_userspace.rst
|
|
usermode_sharedmem.rst
|