Skip to content

[BUG] [ARC SEM] Memory Read Protection Violation from Secure MPU on exit from interrupt #331

Open
@jzbydniewski

Description

@jzbydniewski

What I observe is that in some circumstances (it started appearing after enabling few more interrupts and threads) CPU ends up catching Memory Read Protection Violation from Secure MPU exception on exit from interrupt in arc_support.s

portable/ThirdParty/GCC/ARC_EM_HS/arc_support.s
519: rtie

Contents of some debug registers once in the exception handler:

EFA: 0x00000000
ECR: 0x00060124

MPU_ECR (0x420) = 0x605FF, meaning below:

- bits 31:16 -> EC_CODE = 0x6  -> vector number of the EV_ProtV exception
- bits 15:12 reserved
- bits 11:10 -> SEC = 0x01 -> Secure violation has occurred; secure resources are being accessed in the normal mode
- bits 9:8   -> VT     = 0x01 -> Data Read Violation
- bits 7:0   -> MR    = 0xFF -> Access missed all regions

Debugging with gdb reveals that SEC_STAT.IRM bit is being reset to 0 after call to dispatcher from interrupt context

portable/ThirdParty/GCC/ARC_EM_HS/arc_support.s
207: bl dispatcher /* r0->pxCurrentTCB */

After IRM is set to 0, the exit from interrupt (RTIE instruction) results in mode switch from secure kernel to normal kernel mode. In my case all memory is marked in MPU as “secure” so this results in CPU exception.

I can see that a similar sounding bug was raised for Zephyr and fixed:
zephyrproject-rtos/zephyr#18725

I tried applying a similar fix for FreeRTOS and the following changes in interrupt entry/exit macros resolve my issue:

arc_asm_common.h from https://github.com/foss-for-synopsys-dwc-arc-processors/embarc_bsp/blob/topic-freertos-demo/include/arc/v2/arc_asm_common.h

--- arc_asm_common.h
+++ arc_asm_common.h
@@ -516,6 +516,9 @@ PUSH gp
 PUSH fp
 PUSH ilink
 PUSH r30
+lr r3, [0x09] /* store SEC_STAT.IRM */
+and r3, r3, 0x8
+PUSH r3

[…]

.macro INTERRUPT_EPILOGUE
 add sp, sp, 4             /* skip bta */

+POP r3 /* restore SEC_STAT.IRM */
+sflag r3
 POP r30
 POP ilink
 POP fp

Please note this is simplified fix as the IRM is stored/restored on interrupt entry/exit. I suspect that proper fix would do that on task context store/restore.

Compiler: Synopsys ARC GCC 2020.03, but it seems irrelevant
Platform: Synopsys ARC SEM

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workinghelp wantedExtra attention is needed

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions