Lines Matching +full:portable +full:- +full:device
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
57 memory domain. Portable code should not assume this.
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
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
88 hardware-enforced memory protections.
90 - We prevent re-entry from user to supervisor mode except through the
91 kernel-defined system calls and interrupt handlers.
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.
146 manipulation of kernel objects is done through system call interfaces. Device
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
160 parameter error checking for kernel object or device driver APIs. Access from
167 - Thread stacks are defined in such a way that exceeding the specified stack
174 All kernel objects, thread stacks, and device driver instances must be defined
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
187 instantiate device drivers, or define system calls, regardless of what
190 - Loaded object code that does not come from a verified source should always