As luck would have it, the TSS for the main IA task has
all the information we need, populate an exception stack
frame with it.
The double-fault handler just stashes data and makes the main
hardware thread runnable again, and processing of the
exception continues from there.
We check the first byte before the faulting ESP value to see
if the stack pointer had run up to a non-present page, a sign
that this is a stack overflow and not a double fault for
some other reason.
Stack overflows in kernel mode are now recoverable for non-
essential threads, with the caveat that we hope we weren't in
a critical section updating kernel data structures when it
happened.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Historically, stacks were just character buffers and could be treated
as such if the user wanted to look inside the stack data, and also
declared as an array of the desired stack size.
This is no longer the case. Certain architectures will create a memory
region much larger to account for MPU/MMU guard pages. Unfortunately,
the kernel interfaces treat both the declared stack, and the valid
stack buffer within it as the same char * data type, even though these
absolutely cannot be used interchangeably.
We introduce an opaque k_thread_stack_t which gets instantiated by
K_THREAD_STACK_DECLARE(), this is no longer treated by the compiler
as a character pointer, even though it really is.
To access the real stack buffer within, the result of
K_THREAD_STACK_BUFFER() can be used, which will return a char * type.
This should catch a bunch of programming mistakes at build time:
- Declaring a character array outside of K_THREAD_STACK_DECLARE() and
passing it to K_THREAD_CREATE
- Directly examining the stack created by K_THREAD_STACK_DECLARE()
which is not actually the memory desired and may trigger a CPU
exception
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Show that this mechanism can detect stack overflows with the
guard page. We only do it once since are are in an alternate
IA HW task after it happens.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This will prepare test cases and samples with metadata and information
that will be consumed by the sanitycheck script which will be changed to
parse YAML files instead of ini.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
- _SysFatalErrorHandler is supposed to be user-overridable.
The test case now installs its own handler to show that this
has happened properly.
- Use TC_PRINT() TC_ERROR() macros
- Since we have out own _SysFatalErrorHandler, show that
k_panic() works
- Show that _SysFatalErrorHandler gets invoked with the expected
reason code for some of the scenarios.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
For all arches except ARC, enable stack sentinel and test that
some common stack violations trigger exceptions.
For ARC, use the hardware stack checking feature.
Additional testcase.ini blocks may be added to do stack bounds checking
for MMU/MPU-based stack protection schemes.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This test generates a fault as part of the test,hence make the
test-suite aware of that by tagging it.
Signed-off-by: Rishi Khare <rishi.khare@intel.com>
We want to show that if a non-essential thread gets a fatal exception,
that thread gets aborted but the rest of the system works properly.
We also test that k_oops() does the same.
Issue: ZEP-2052
Change-Id: I0f88bcae865bf12bb91bb55e50e8ac9721672434
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
