Andrew Boie 3a0f6848e4 kernel: policy change for uninitailized objects ... The old policy was that objects that are not marked as initialized may be claimed by any thread, user or kernel. This has some undesirable implications: - Kernel objects that were initailized at build time via some _<object name>_INITIALIZER macro, not intended for userspace to ever use, could be 'stolen' if their memory addresses were figured out and _k_object_init() was never called on them. - In general, a malicious thread could initialize all unclaimed objects it could find, resulting in denial of service for the threads that these objects were intended for. Now, performing any operation in user mode on a kernel object, initialized or not, required that the calling user thread have permission on it. Such permission would have to be explicitly granted or inherited from a supervisor thread, as with this change only supervisor thread will be able to claim uninitialized objects in this way. If an uninitialized kernel object has permissions granted to multiple threads, whatever thread actually initializes the object will reset all permission bits to zero and grant only the calling thread access to that object. In other words, granting access to an uninitialized object to several threads means that "whichever of these threads (or any kernel thread) who actually initializes this object will obtain exclusive access to that object, which it then may grant to other threads as it sees fit." Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>		2017-10-10 09:26:29 -07:00
..
include
alert.c
atomic_c.c
compiler_stack_protect.c
device.c
errno.c
idle.c
init.c
int_latency_bench.c
Kconfig
Kconfig.event_logger
Kconfig.power_mgmt
mailbox.c
Makefile
mem_domain.c
mem_slab.c
mempool.c
msg_q.c
mutex.c
pipes.c
poll.c
pthread.c
queue.c
sched.c
sem.c
stack.c
sys_clock.c
system_work_q.c
thread_abort.c
thread.c
timer.c
userspace_handler.c
userspace.c
version.c
work_q.c