Lines Matching full:kernel

10 isolated from other user mode threads and from the kernel. A flawed or
12 of another thread or the kernel, and cannot interfere with or
13 control another user mode thread or the kernel.
17 - The kernel can protect against many unintentional programming errors which
20 - The kernel can sandbox complex data parsers such as interpreters, network
22   cannot compromise the kernel or other threads.
24 - The kernel can support the notion of multiple logical "applications", each
60     on read-only basis, kernel-wide. This policy may be adjusted.
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
71   kernel. This includes:
73   - Using the wrong kernel object type.
80   - Use of kernel objects that are not in a proper initialization state.
84 - We prevent invoking system calls to functions excluded by the kernel
87 - We prevent disabling of or tampering with kernel-defined and
91   kernel-defined system calls and interrupt handlers.
94   except to the extent to which this is supported by kernel system calls.
98 - The kernel itself, and any threads that are executing in supervisor mode,
104 - The kernel build is assumed to be trusted. There is considerable build-time
105   logic for creating the tables of valid kernel objects, defining system calls,
110   kernel mode that exposes private kernel data structures to a user thread. RAM
111   for kernel objects should always be configured as supervisor-only.
114   assign them permissions to kernel objects. In general, all C and header
115   files that are part of the kernel build producing zephyr.elf are assumed to
142   domains, or via kernel objects such as semaphores and pipes.
144 - User threads cannot directly access memory belonging to kernel objects.
145   Although pointers to kernel objects are used to reference them, actual
146   manipulation of kernel objects is done through system call interfaces. Device
147   drivers and threads stacks are also considered kernel objects. This ensures
148   that any data inside a kernel object that is private to the kernel cannot be
151 - User threads by default have no permission to access any kernel object or
154   the receiving thread object and the kernel object being granted access to.
156   permissions of all kernel objects granted to the parent, except the parent
160   parameter error checking for kernel object or device driver APIs. Access from
174 All kernel objects, thread stacks, and device driver instances must be defined
176 kernel objects will need to go through pre-defined pools of available objects.
179 for execution after the kernel starts:
181 - Loaded object code will not be able to define any kernel objects that will be
182   recognized by the kernel. This code will instead need to use APIs for
183   requesting kernel objects from pools.
185 - Similarly, since the loaded object code will not be part of the kernel build