Skip to content

Commit 4c59c85

Browse files
author
Andy Gross
committed
doc: kernel: usermode: Add MPU stack and userspace documentation
This patch adds documentation on the design and implementation of stack objects for architectures which utilize MPU backed stack and memory protection. Signed-off-by: Andy Gross <[email protected]>
1 parent c614a90 commit 4c59c85

File tree

3 files changed

+93
-0
lines changed

3 files changed

+93
-0
lines changed
+65
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,65 @@
1+
.. _mpu_stack_objects:
2+
3+
MPU Stack Objects
4+
#################
5+
6+
Thread Stack Creation
7+
*********************
8+
9+
Thread stacks are declared statically with :c:macro:`K_THREAD_STACK_DEFINE()`
10+
or embedded within structures using c:macro:`K_THREAD_STACK_MEMBER()`
11+
12+
For architectures which utilize memory protection unit (MPU) hardware,
13+
stacks are physically contiguous allocations. This contiguous allocation
14+
has implications for the placement of stacks in memory, as well as the
15+
implementation of other features such as stack protection and userspace. The
16+
implications for placement are directly attributed to the alignment
17+
requirements for MPU regions. This is discussed in the memory placement
18+
section below.
19+
20+
Stack Guards
21+
************
22+
23+
Stack protection mechanisms require hardware support that can restrict access
24+
to memory. Memory protection units can provide this kind of support.
25+
The MPU provides a fixed number of regions. Each region contains information
26+
about the start, end, size, and access attributes to be enforced on that
27+
particular region.
28+
29+
Stack guards are implemented by using a single MPU region and setting the
30+
attributes for that region to not allow write access. If invalid accesses
31+
occur, a fault ensues. The stack guard is defined at the bottom (the lowest
32+
address) of the stack.
33+
34+
Memory Placement
35+
****************
36+
37+
During stack creation, a set of constraints are enforced on the allocation of
38+
memory. These constraints include determining the alignment of the stack and
39+
the correct sizing of the stack. During linking of the binary, these
40+
constraints are used to place the stacks properly.
41+
42+
The main source of the memory constraints is the MPU design for the SoC. The
43+
MPU design may require specific constraints on the region definition. These
44+
can include alignment of beginning and end addresses, sizes of allocations,
45+
or even interactions between overlapping regions.
46+
47+
Some MPUs require that each region be aligned to a power of two. These SoCs
48+
will have :option:`CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT` defined.
49+
This means that a 1500 byte stack should be aligned to a 2kB boundary and the
50+
stack size should also be adjusted to 2kB to ensure that nothing else is
51+
placed in the remainder of the region. SoCs which include the unmodified ARM
52+
v7m MPU will have these constraints.
53+
54+
Some ARM MPUs use start and end addresses to define MPU regions and both the
55+
start and end addresses require 32 byte alignment. An example of this kind of
56+
MPU is found in the NXP FRDM K64F.
57+
58+
MPUs may have a region priority mechanisms that use the highest priority region
59+
that covers the memory access to determine the enforcement policy. Others may
60+
logically OR regions to determine enforcement policy.
61+
62+
Size and alignment constraints may result in stack allocations being larger
63+
than the requested size. Region priority mechanisms may result in
64+
some added complexity when implementing stack guards.
65+

doc/kernel/usermode/mpu_userspace.rst

+26
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
.. _mpu_userspace:
2+
3+
MPU Backed Userspace
4+
####################
5+
6+
The MPU backed userspace implementation requires the creation of a secondary
7+
set of stacks. These stacks exist in a 1:1 relationship with each thread stack
8+
defined in the system. The privileged stacks are created as a part of the
9+
build process.
10+
11+
A post-build script ``gen_priv_stacks.py`` scans the generated
12+
ELF file and finds all of the thread stack objects. A set of priviliged
13+
stacks, a lookup table, and a set of helper functions are created and added
14+
to the image.
15+
16+
During the process of dropping a thread to user mode, the privileged stack
17+
information is filled in and later used by the swap and system call
18+
infrastructure to configure the MPU regions properly for the thread stack and
19+
guard (if applicable).
20+
21+
During system calls, the user mode thread's access to the system call and the
22+
passed-in parameters are all validated. The user mode thread is then elevated
23+
to privileged mode, the stack is switched to use the privileged stack, and the
24+
call is made to the specified kernel API. On return from the kernel API, the
25+
thread is set back to user mode and the stack is restored to the user stack.
26+

doc/kernel/usermode/usermode.rst

+2
Original file line numberDiff line numberDiff line change
@@ -188,3 +188,5 @@ for execution after the kernel starts:
188188
kernelobjects.rst
189189
syscalls.rst
190190
memory_domain.rst
191+
mpu_stack_objects.rst
192+
mpu_userspace.rst

0 commit comments

Comments
 (0)