• 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 in reply to Joseph Yiu
    Thanks again Joseph! Questions are motivated by the following :-)
    1) I'm not an RTOS developer but provide code that could be included in RTOS's and middleware code. So the code is trusted by firmware but one can never say if they are trusted they are immune to exploitation. I am trying to assess the worst that could happen if my code is exploited.
    2) I've done a fair bit of work on the ARMv8-A and I'm trying to understand the subtle(and not so subtle)differences between the two architectures.
    3) My questions are motivated by exploits like this(and related exploits): bits-please.blogspot.com/.../extracting-qualcomms-keymaster-keys.html :-). If I run an isolated unprivileged thread/process/app in the secure world and I get exploited, I wouldn't want all of secure world to be exploited because of this. or if somebody else code is exploited, I wouldn't want my code to be rendered useless.
    4) I like the NSC access restriction solution. I think making the NSC region protected by the MPU as secure privileged access only, would give me a model like the ARMv8-A TrustZone. If I mark the NSC region as privileged only, then all secure API's must go through the non secure RTOS kernel, then to the secure RTOS kernel, which can verify the non secure state, then switch to unprivileged thread mode, thus ensuring secure API's always run in secure thread mode. of course this would make all the ARMv8-M optimizations to make switching worlds quick, much slower!

    My questions have been answered. Thanks! :)
Reply
  • 0 in reply to Joseph Yiu
    Thanks again Joseph! Questions are motivated by the following :-)
    1) I'm not an RTOS developer but provide code that could be included in RTOS's and middleware code. So the code is trusted by firmware but one can never say if they are trusted they are immune to exploitation. I am trying to assess the worst that could happen if my code is exploited.
    2) I've done a fair bit of work on the ARMv8-A and I'm trying to understand the subtle(and not so subtle)differences between the two architectures.
    3) My questions are motivated by exploits like this(and related exploits): bits-please.blogspot.com/.../extracting-qualcomms-keymaster-keys.html :-). If I run an isolated unprivileged thread/process/app in the secure world and I get exploited, I wouldn't want all of secure world to be exploited because of this. or if somebody else code is exploited, I wouldn't want my code to be rendered useless.
    4) I like the NSC access restriction solution. I think making the NSC region protected by the MPU as secure privileged access only, would give me a model like the ARMv8-A TrustZone. If I mark the NSC region as privileged only, then all secure API's must go through the non secure RTOS kernel, then to the secure RTOS kernel, which can verify the non secure state, then switch to unprivileged thread mode, thus ensuring secure API's always run in secure thread mode. of course this would make all the ARMv8-M optimizations to make switching worlds quick, much slower!

    My questions have been answered. Thanks! :)
Children
  • 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
  • 0 in reply to Joseph Yiu
    Thanks Joseph! Makes things very clear. :)