Fixed condition and wrong Kconfig name, shoud be CONFIG_CPU_HAS_NXP_MPU
instead of only CPU_HAS_NXP_MPU.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This commit removes all MPU-related (ARM_CORE_MPU and NXP_MPU)
options exept ARM_MPU, which becomes master switch controlling
MPU support on ARM.
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
The return of memset is never checked. This patch explicitly ignore
the return to avoid MISRA-C violations.
The only directory excluded directory was ext/* since it contains
only imported code.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
irq_lock returns an unsigned int, though, several places was using
signed int. This commit fix this behaviour.
In order to avoid this error happens again, a coccinelle script was
added and can be used to check violations.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
In arc, privileged stack is merged into defined stack. So
the real stack size should add privileged stack size.
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
The generation of Stack Corruptions reports is, now, supported
in ARM SOCs with the ARM MPU (CONFIG_ARM_MPU). Therefore, this
commit removes the workaround for ARM architecture in
tests/kernel/fatal/ and keeps it only for SOCs with the NXP MPU
(CONFIG_MXU_MPU).
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
An errant commit accidentally disabled all testing of
hardware-based stack protection. Restore it, and work
around a problem with how these kinds of exceptions are
reported on ARM until #7706 is fixed.
We need to globally disable user mode due to how the
select statements in Kconfig work, the stack sentinel
is incompatible with user mode.
Some build warnings when compiling as native_posix
fixed.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This test had to special case ARM, where error handlers are not
NORETURN functions. The xtensa/asm2 layer has the same behavior
(albeit for a different reason). Add it to the list, and clean up the
explanation a bit.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The xtensa-asm2 work included a patch that added nano_internal.h
includes in lots of places that needed to have _Swap defined, because
it had to break a cycle and this no longer got pulled in from the arch
headers.
Unfortunately those new includes created new and more amusing cycles
elsewhere which led to breakage on other platforms.
Break out the _Swap definition (only) into a separate header and use
that instead. Cleaner. Seems not to have any more hidden gotchas.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
_Swap() is defined in nano_internal.h. Everything calls _Swap().
Pretty much nothing that called _Swap() included nano_internal.h,
expecting it to be picked up automatically through other headers (as
it happened, from the kernel arch-specific include file). A new
_Swap() is going to need some other symbols in the inline definition,
so I needed to break that cycle. Now nothing sees _Swap() defined
anymore. Put nano_internal.h everywhere it's needed.
Our kernel includes remain a big awful yucky mess. This makes things
more correct but no less ugly. Needs cleanup.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The test case used a stack which was not aligned to 4kB. Hence an
assert was catching this issue.
GH-5539
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
For the POSIX arch we rely on the native OS to handle
segfaults, and stack overflows.
So that we can debug them with normal native tools.
Therefore these 2 are ifdef'ed for this arch in this test
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
Currently this is defined as a k_thread_stack_t pointer.
However this isn't correct, stacks are defined as arrays. Extern
references to k_thread_stack_t doesn't work properly as the compiler
treats it as a pointer to the stack array and not the array itself.
Declaring as an unsized array of k_thread_stack_t doesn't work
well either. The least amount of confusion is to leave out the
pointer/array status completely, use pointers for function prototypes,
and define K_THREAD_STACK_EXTERN() to properly create an extern
reference.
The definitions for all functions and struct that use
k_thread_stack_t need to be updated, but code that uses them should
be unchanged.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
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>
- _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>
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>
