Secure stack check

[vonhust]

this PR is used to enable the stack check when arc is in secure mode.

If arc is in secure mode, SSC bit of sec_stat, not SC bit of status32, is used to enable/disable stack check.

Fixes #8313

[codecov-io]

Codecov Report

Merging #9024 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #9024   +/-   ##
=======================================
  Coverage   52.15%   52.15%           
=======================================
  Files         212      212           
  Lines       25916    25916           
  Branches     5582     5582           
=======================================
  Hits        13517    13517           
  Misses      10149    10149           
  Partials     2250     2250

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 84c352d...201b260. Read the comment docs.

[ruuddw]

Looks ok, few discussion topics:

• I don't see corresponding stack check enables in most cases where checking is disabled (exceptions, interrupts), assume that is handled implicitly by restore of the original STAT/SEC_STAT on interrupt return?
• is it necessary to always disable stack checking for interrupt processing? Would it be possible to keep stack checking enabled and only disable on reprogramming the stack boundary registers on a context switch?

[vonhust]

Hi Ruud | I don't see corresponding stack check enables in most cases where checking is disabled (exceptions, interrupts), assume that is handled implicitly by restore of the original STAT/SEC_STAT on interrupt return? Yes, it is handled implicitly by restore of the original STAT/SEC_STAT on interrupt return. | is it necessary to always disable stack checking for interrupt processing? Would it be possible to keep stack checking enabled and only disable on reprogramming the stack boundary registers on a context switch? In interrupt processing, the stack will be switched to isr stack, if stack check is not disabled, the stack check fail exception will be raised, as the new sp will not be in the range from STACK_TOP to STACK_BASE. Of course, we can reprogram the stack check reg to match the change of sp, but it means we need to save the old one and restore it later. More instructions are required, it will affect the interrupt latency. One more, if the interrupt stack is overflow, there will be no way to recover from this cause, the system has to stop. In zephyr, it seems the stack protection is mainly for thread stack. For isr stack, it needs more discussion. From: ruuddw [mailto:notifications@github.com] Sent: 2018年8月2日 21:27 To: zephyrproject-rtos/zephyr <zephyr@noreply.github.com> Cc: Wayne Ren <Wei.Ren@synopsys.com>; Author <author@noreply.github.com> Subject: Re: [zephyrproject-rtos/zephyr] Secure stack check (#9024) Looks ok, few discussion topics: * I don't see corresponding stack check enables in most cases where checking is disabled (exceptions, interrupts), assume that is handled implicitly by restore of the original STAT/SEC_STAT on interrupt return? * is it necessary to always disable stack checking for interrupt processing? Would it be possible to keep stack checking enabled and only disable on reprogramming the stack boundary registers on a context switch? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_zephyrproject-2Drtos_zephyr_pull_9024-23issuecomment-2D409925389&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=uIRv5OnfaYG5_34mbrNlSdByDrbpAfi15TvQ5YKDOG8&m=ZMUHGvxja3uOHWHlHtAew-HgvPq0sv6ZHDiv3sFlKng&s=Trnf-ptyQczDg9yuNWttZw-OzgHz58m7uaCMzbJi8Kw&e=>, or mute the thread<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AFB9O4P3TZ-5FzOe9QhL3eP31gA3-2DxhlDYks5uMv4VgaJpZM4VWBoF&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=uIRv5OnfaYG5_34mbrNlSdByDrbpAfi15TvQ5YKDOG8&m=ZMUHGvxja3uOHWHlHtAew-HgvPq0sv6ZHDiv3sFlKng&s=hM7BV1_ZSvWie-wkVqvHgpKmhrSe7DVQdUc9UBSiSyA&e=>.

[ruuddw]

Looks ok, and sanitycheck is (almost) clean now for nsim_em and nsim_sem. Few remaining failures, but these are understood and expected.
@nashif I believe this PR is ready for merging now.