OrgZephyr/zephyr
OrgZephyr
/
zephyr
mirror of https://github.com/zephyrproject-rtos/zephyr.git
1
0
Fork 0
Code Issues Releases Wiki Activity
zephyr/include/linker/kobject.ld

44 lines
1.4 KiB
Plaintext
Raw Normal View History

kernel: introduce object validation mechanism 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>
2017-08-23 04:15:23 +08:00
/*
* 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*")
kernel: threads: assign index no. to dynamically created threads Kernel threads created at build time have unique indexes to map them into various bitarrays. This patch extends these indexes to dynamically created threads where the associated kernel objects are allocated at runtime. Fixes: #9081 Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2018-08-09 02:23:16 +08:00
#ifndef LINKER_PASS2
#ifdef CONFIG_DYNAMIC_OBJECTS
PROVIDE(_thread_idx_map = .);
. += CONFIG_MAX_THREAD_BYTES;
#endif
#endif
kernel: introduce object validation mechanism 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>
2017-08-23 04:15:23 +08:00
/* 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 */