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>

include/linker/common-ram.ld

@@ -22,6 +22,17 @@
 		_static_thread_data_list_end = .;
 	} GROUP_DATA_LINK_IN(RAMABLE_REGION, ROMABLE_REGION)
 
+#ifdef CONFIG_USERSPACE
+	/* All kernel objects within are assumed to be either completely
+	 * initialized at build time, or initialized automatically at runtime
+	 * via iteration before the POST_KERNEL phase.
+	 *
+	 * These two symbols only used by gen_kobject_list.py
+	 */
+
+	_static_kernel_objects_begin = .;
+#endif /* CONFIG_USERSPACE */
+
 	SECTION_DATA_PROLOGUE(_k_timer_area, (OPTIONAL), SUBALIGN(4))
 	{
 		_k_timer_list_start = .;
@@ -176,3 +187,7 @@
 		KEEP(*(SORT_BY_NAME(".net_l2.data*")))
 		__net_l2_data_end = .;
 	} GROUP_DATA_LINK_IN(RAMABLE_REGION, ROMABLE_REGION)
+
+#ifdef CONFIG_USERSPACE
+	_static_kernel_objects_end = .;
+#endif

include/linker/kobject-rom.ld

@@ -0,0 +1,13 @@
+/*
+ * Copyright (c) 2017 Intel Corporation
+ *
+ * SPDX-License-Identifier: Apache-2.0
+ */
+
+#ifdef CONFIG_USERSPACE
+        /* Kept in RAM on non-XIP */
+#ifdef CONFIG_XIP
+	*(".kobject_data.rodata*")
+#endif
+#endif /* CONFIG_USERSPACE */
+

include/linker/kobject-text.ld

@@ -0,0 +1,25 @@
+#ifndef KOBJECT_TEXT_AREA
+#if defined(CONFIG_DEBUG) || defined(CONFIG_STACK_CANARIES)
+#define KOBJECT_TEXT_AREA	256
+#else
+#define KOBJECT_TEXT_AREA	78
+#endif
+#endif
+
+#ifdef CONFIG_USERSPACE
+	/* We need to reserve room for the gperf generated hash functions.
+	 * Fortunately, unlike the data tables, the size of the code is
+	 * reasonably predictable; on x86 usually about 44 bytes with -Os.
+	 *
+	 * The linker will error out complaining that the location pointer
+	 * is moving backwards if the reserved room isn't large enough.
+	 */
+	_kobject_text_area_start = .;
+	*(".kobject_data.text*")
+	_kobject_text_area_end = .;
+#ifndef LINKER_PASS2
+	PROVIDE(_k_object_find = .);
+#endif
+	. += KOBJECT_TEXT_AREA - (_kobject_text_area_end - _kobject_text_area_start);
+#endif /* CONFIG_USERSPACE */
+

include/linker/kobject.ld

@@ -0,0 +1,36 @@
+/*
+ * 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 */
+