Lines Matching +full:read +full:- +full:only
15 Example use-cases of Zephyr's user mode features:
17 - The kernel can protect against many unintentional programming errors which
20 - The kernel can sandbox complex data parsers such as interpreters, network
21 protocols, and filesystems such that malicious third-party code or data
24 - The kernel can support the notion of multiple logical "applications", each
31 For threads running in a non-privileged CPU state (hereafter referred to as
34 - We prevent access to memory not specifically granted, or incorrect access to
36 read-only area.
38 - Access to thread stack buffers will be controlled with a policy which
41 - A user thread will by default have read/write access to its own stack
44 - A user thread will never by default have access to user thread stacks
47 - A user thread will never by default have access to thread stacks owned
51 - A user thread may have read/write access to the stacks of other user
54 - On MPU systems, threads may only access their own stack buffer.
56 - On MMU systems, threads may access any user thread stack in the same
59 - By default, program text and read-only data are accessible to all threads
60 on read-only basis, kernel-wide. This policy may be adjusted.
62 - User threads by default are not granted default access to any memory
65 - We prevent use of device drivers or kernel objects not specifically granted,
69 - We validate kernel or driver API calls with incorrect parameters that would
73 - Using the wrong kernel object type.
75 - Using parameters outside of proper bounds or with nonsensical values.
77 - Passing memory buffers that the calling thread does not have sufficient
78 access to read or write, depending on the semantics of the API.
80 - Use of kernel objects that are not in a proper initialization state.
82 - We ensure the detection and safe handling of user mode stack overflows.
84 - We prevent invoking system calls to functions excluded by the kernel
87 - We prevent disabling of or tampering with kernel-defined and hardware-
90 - We prevent re-entry from user to supervisor mode except through the kernel-
93 - We prevent the introduction of new executable code by user mode threads,
98 - The kernel itself, and any threads that are executing in supervisor mode,
101 - The toolchain and any supplemental programs used by the build system are
104 - The kernel build is assumed to be trusted. There is considerable build-time
109 - We can't protect against mistakes made in memory domain configuration done in
111 for kernel objects should always be configured as supervisor-only.
113 - It is possible to make top-level declarations of user mode threads and
118 - We do not protect against denial of service attacks through thread CPU
121 threads of the same priority if time-slicing is not enabled.
123 - There are build-time defined limits on how many threads can be active
126 - Stack overflows for threads running in supervisor mode may be caught,
129 High-level Policy Details
132 Broadly speaking, we accomplish these thread-level memory protection goals
135 - Any user thread will only have access to a subset of memory:
136 typically its stack, program text, read-only data, and any partitions
144 - User threads cannot directly access memory belonging to kernel objects.
151 - User threads by default have no permission to access any kernel object or
159 - For performance and footprint reasons Zephyr normally does little or no
164 other means, and verify proper read/write access to any memory buffers
167 - Thread stacks are defined in such a way that exceeding the specified stack
175 at build time if they are to be used from user mode. Dynamic use-cases for
176 kernel objects will need to go through pre-defined pools of available objects.
181 - Loaded object code will not be able to define any kernel objects that will be
185 - Similarly, since the loaded object code will not be part of the kernel build
190 - Loaded object code that does not come from a verified source should always