mirror of
https://github.com/zephyrproject-rtos/zephyr
synced 2025-08-26 06:35:54 +00:00
945af95f42
All system calls made from userspace which involve pointers to kernel objects (including device drivers) will need to have those pointers validated; userspace should never be able to crash the kernel by passing it garbage. The actual validation with _k_object_validate() will be in the system call receiver code, which doesn't exist yet. - CONFIG_USERSPACE introduced. We are somewhat far away from having an end-to-end implementation, but at least need a Kconfig symbol to guard the incoming code with. Formal documentation doesn't exist yet either, but will appear later down the road once the implementation is mostly finalized. - In the memory region for RAM, the data section has been moved last, past bss and noinit. This ensures that inserting generated tables with addresses of kernel objects does not change the addresses of those objects (which would make the table invalid) - The DWARF debug information in the generated ELF binary is parsed to fetch the locations of all kernel objects and pass this to gperf to create a perfect hash table of their memory addresses. - The generated gperf code doesn't know that we are exclusively working with memory addresses and uses memory inefficently. A post-processing script process_gperf.py adjusts the generated code before it is compiled to work with pointer values directly and not strings containing them. - _k_object_init() calls inserted into the init functions for the set of kernel object types we are going to support so far Issue: ZEP-2187 Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
37 lines
1.2 KiB
Plaintext
37 lines
1.2 KiB
Plaintext
/*
|
|
* Copyright (c) 2017 Intel Corporation
|
|
*
|
|
* SPDX-License-Identifier: Apache-2.0
|
|
*/
|
|
|
|
#ifdef CONFIG_USERSPACE
|
|
/* Constraints:
|
|
*
|
|
* - changes to the size of this section between build phases
|
|
* *must not* shift the memory address of any kernel obejcts,
|
|
* since it contains a hashtable of the memory addresses of those
|
|
* kernel objects
|
|
*
|
|
* - It is OK if this section itself is shifted in between builds; for
|
|
* example some arches may precede this section with generated MMU
|
|
* page tables which are also unpredictable in size.
|
|
*
|
|
* The size of the
|
|
* gperf tables is both a function of the number of kernel objects,
|
|
* *and* the specific memory addresses being hashed. It is not something
|
|
* that can be predicted without actually building and compling it.
|
|
*/
|
|
SECTION_DATA_PROLOGUE(kobject_data, (OPTIONAL),)
|
|
{
|
|
*(".kobject_data.data*")
|
|
|
|
/* This is also unpredictable in size, and has the same constraints.
|
|
* On XIP systems this will get put at the very end of ROM.
|
|
*/
|
|
#ifndef CONFIG_XIP
|
|
*(".kobject_data.rodata*")
|
|
#endif
|
|
} GROUP_DATA_LINK_IN(RAMABLE_REGION, ROMABLE_REGION)
|
|
#endif /* CONFIG_USERSPACE */
|
|
|