• State Accepted Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 11 replies
  • Subscribers 352 subscribers
  • Views 34893 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Security State transitions - Processor Mode

Pierre

Edit: CONTROL.nPRIV is actually banked so I modified my question

Hi,

I have a question regarding S/NS state transitions and PE modes.

From what I read in the ARMv8-M ARM there is no restriction in terms of PE mode for state transitions.

The PE mode is preserved during the State transition (IPSR is not banked, and not modified by transition mechanims) but the privileged flag is (CONTROL.nPRIV is banked), right?

Is the following correct:

  • I am for example running in NS unprivileged Thread Mode, say I am calling an NSC veneer and thus switching to Secure State. I would then execute the target function in S state in Thread Mode but I can't be sure of the privilege level, it would be the last privilege level used in S (because CONTROL.nPRIV is banked). The only predictable case is when I transition from Handler Mode which is always privileged.
  • When running in S state, if I BLXNS into an NS function the current PE Mode is preserved but the privilege level can't be predicted (as in previous bullet).

?

Am I correct? If so is it not an issue?

Thanks

Parents
  • 0 Arm Employee Badge in reply to raghu.ncstate
    Hi Radhu,

    Regarding the NSC method I am thinking of, is to ensure that no 3rd party Secure unprivileged code would be marked as NSC, and only Secure world owner can provide entry points (with correct NSC setup obviously). The actual calls to unprivileged Secure APIs can only be made after a security check. So effectively a software wrapper is need for the Secure unprivileged API.

    The security check is quite simple. If CONTROL_S[0] is set to 1 then you only need to check if current IPSR is 0 (thread). Then you are sure that the API will execute in Secure unprivileged state.

    If you make the NSC region privilege access only, then a NS thread calling the Secure API will have a Secure MemManage fault as the SG instruction is executed. You can resolve that in the fault handler but this increases overhead.
    regards,
    Joseph
Reply
  • 0 Arm Employee Badge in reply to raghu.ncstate
    Hi Radhu,

    Regarding the NSC method I am thinking of, is to ensure that no 3rd party Secure unprivileged code would be marked as NSC, and only Secure world owner can provide entry points (with correct NSC setup obviously). The actual calls to unprivileged Secure APIs can only be made after a security check. So effectively a software wrapper is need for the Secure unprivileged API.

    The security check is quite simple. If CONTROL_S[0] is set to 1 then you only need to check if current IPSR is 0 (thread). Then you are sure that the API will execute in Secure unprivileged state.

    If you make the NSC region privilege access only, then a NS thread calling the Secure API will have a Secure MemManage fault as the SG instruction is executed. You can resolve that in the fault handler but this increases overhead.
    regards,
    Joseph
Children