Kernel object metadata had an extra data field added recently to
store bounds for stack objects. Use this data field to assign
IDs to thread objects at build time. This has numerous advantages:
* Threads can be granted permissions on kernel objects before the
thread is initialized. Previously, it was necessary to call
k_thread_create() with a K_FOREVER delay, assign permissions, then
start the thread. Permissions are still completely cleared when
a thread exits.
* No need for runtime logic to manage thread IDs
* Build error if CONFIG_MAX_THREAD_BYTES is set too low
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We also need macros to assert that an object must be in an
uninitialized state. This will be used for validating thread
and stack objects to k_thread_create(), which must not be already
in use.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This is too powerful for user mode, the other access APIs
require explicit permissions on the threads that are being
granted access.
The API is no longer exposed as a system call and hence will
only be usable by supervisor threads.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
It's currently too easy to run out of thread IDs as they
are never re-used on thread exit.
Now the kernel maintains a bitfield of in-use thread IDs,
updated on thread creation and termination. When a thread
exits, the permission bitfield for all kernel objects is
updated to revoke access for that retired thread ID, so that
a new thread re-using that ID will not gain access to objects
that it should not have.
Because of these runtime updates, setting the permission
bitmap for an object to all ones for a "public" object doesn't
work properly any more; a flag is now set for this instead.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Use some preprocessor trickery to automatically deduce the amount of
arguments for the various _SYSCALL_HANDLERn() macros. Makes the grunt
work of converting a bunch of kernel APIs to system calls slightly
easier.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Does the opposite of k_object_access_grant(); the provided thread will
lose access to that kernel object.
If invoked from userspace the caller must hace sufficient access
to that object and permission on the thread being revoked access.
Fix documentation for k_object_access_grant() API to reflect that
permission on the thread parameter is needed as well.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We now have macros which should significantly reduce the amount of
boilerplate involved with defining system call handlers.
- Macros which define the proper prototype based on number of arguments
- "SIMPLE" variants which create handlers that don't need anything
other than object verification
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
- Dumping error messages split from _k_object_validate(), to avoid spam
in test cases that are expected to have failure result.
- _k_object_find() prototype moved to syscall_handler.h
- Clean up k_object_access() implementation to avoid double object
lookup and use single validation function
- Added comments, minor whitespace changes
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Use new _SYSCALL_OBJ/_SYSCALL_OBJ_INIT macros.
Use new _SYSCALL_MEMORY_READ/_SYSCALL_MEMORY_WRITE macros.
Some non-obvious checks changed to use _SYSCALL_VERIFY_MSG.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
These modify kernel object metadata and are intended to be callable from
user threads, need a privilege elevation for these to work.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Andrew Boie