zephyr/tests/kernel/mem_protect/userspace/prj.conf

CONFIG_STACK_CANARIES=n
CONFIG_ZTEST=y
CONFIG_INIT_STACKS=y
CONFIG_APPLICATION_DEFINED_SYSCALL=y
CONFIG_THREAD_USERSPACE_LOCAL_DATA=y
CONFIG_TEST_USERSPACE=y
tests: force stack canaries off for two user tests Stack canaries require that the z_libc_partition be added to the memory domain, otherwise user thread access to the stack canary value will result in an MPU/MMU fault. These tests define their own domains to test specific userspace features. Adding another partition to them would be invasive, would potentially break some platforms with a limited number of MPU regions, and these tests are not designed to validate stack canaries anyway, we have other tests for that. Fixes: #17595 Signed-off-by: Andrew Boie <andrew.p.boie@intel.com> 2019-07-17 13:10:53 +08:00			`CONFIG_STACK_CANARIES=n`
tests/kernel/mem_protect/userspace: Add userspace protection tests This is still work-in-progress, but putting it up in case it is helpful to people working in this area and for early comments. Add a set of tests to validate the expected security properties of threads created with K_USER when CONFIG_USERSPACE=y. This can be used as a regression test for architectures that already implement this support and as a validation test for others. I considered incorporating these tests into the existing protection test, but decided against it since protection does not enable or rely upon CONFIG_USERSPACE for its existing tests and passes on everything that provides MPU or MMU support, even without full userspace support. I also considered incorporating these tests into the existing obj_validation test, but decided against it since obj_validation only tests the object validation/permission logic, does not run any user mode threads (or strictly depend on that support), and passes on both x86 and arm today, unlike these tests. That said, I have no strong objections if it would be preferable to fold these into it (and perhaps rename it to be more general). The current tests implemented in this test program verify the following for a thread created with K_USER: is_usermode: is running in usermode priv_insn: cannot invoke privileged insns directly write_control: cannot write to control registers disable_mmu_mpu: cannot disable memory protections (MMU/MPU) read_kernram: cannot read from kernel RAM write_kernram: cannot write to kernel RAM write_kernro: cannot write to kernel rodata write_kerntext: cannot write to kernel text read_kernel_data: cannot read __kernel-marked data write_kernel_data: cannot write __kernel-marked data read_kernel_stack: cannot read the kernel/privileged stack write_kernel_stack: cannot write the kernel/privileged stack pass_user_object: cannot pass a non-kernel object to a syscall pass_noperms_object: cannot pass an object to a syscall without a grant start_kernel_thread: cannot start a kernel (non-user) thread Some of the tests overlap and could possibly be dropped, but it seems harmless to retain them. The particular targets of read/write tests are arbitrary other than meeting the test criteria and can be changed (e.g. in data, rodata, or text) if desired to avoid coupling to kernel implementation details that may change in the future. On qemu_x86, all of the tests pass. And, if you replace all occurrences of ztest_user_unit_test() with ztest_unit_test(), then all of the tests fail (i.e. when the tests are run in kernel mode, they all fail as expected). On frdm_k64f presently (w/o the arm userspace patches), all of the tests fail except for write_kernro and write_kerntext, as expected. ToDo: - Verify that a user thread cannot access data in another memory domain. - Verify that a user thread cannot access another thread's stack. - Verify that a user thread cannot access another thread's kobject. - Verify that k_thread_user_mode_enter() transitions correctly. - Verify that k_object_access_revoke() is enforced. - Verify that syscalls return to user mode upon completion. - Verify that a user thread cannot abuse other svc calls (ARM-specific). - Other suggested properties we should be testing? Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> 2017-11-21 05:39:20 +08:00			`CONFIG_ZTEST=y`
tests: userspace: check stack buffer access The stack information stored in the thread->stack_info fields need to represent the actual writable area for its associated thread. Perform various tests to ensure that the various reported and specified values are in agreement. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com> 2019-02-22 08:00:29 +08:00			`CONFIG_INIT_STACKS=y`
			`CONFIG_APPLICATION_DEFINED_SYSCALL=y`
			`CONFIG_THREAD_USERSPACE_LOCAL_DATA=y`
tests: CONFIG_TEST_USERSPACE now off by default Unlike CONFIG_HW_STACK_PROTECTION, which greatly helps expose stack overflows in test code, activating userspace without putting threads in user mode is of very limited value. Now CONFIG_TEST_USERSPACE is off by default. Any test which puts threads in user mode will need to set CONFIG_TEST_USERSPACE. This should greatly increase sanitycheck build times as there is non-trivial build time overhead to enabling this feature. This also allows some tests which failed the build on RAM-constrained platforms to compile properly. tests/drivers/build_all is a special case; it doesn't put threads in user mode, but we want to ensure all the syscall handlers compile properly. Fixes: #15103 (and probably others) Signed-off-by: Andrew Boie <andrew.p.boie@intel.com> 2019-04-06 06:39:50 +08:00			`CONFIG_TEST_USERSPACE=y`