• 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

    In an application use case, if the Non-secure applications are running in NS unprivileged, it means the hacker need to be break into privileged level first, before they can call the Secure API in handler mode. So there need to be two levels of vulnerabilities.
    But of course, I agree that a hacker can also just buy a chip and try to hack the Secure API....

    > If my secure Api does NOT check control_NS and IPSR....
    >If the unprivileged secure API has an exploit....
    First thing is to rethink why those APIs need to be in Secure world? (If you can't trust them to do the checks properly, I don't think I would put them in the Secure memory :-) )

    ARMv8-M also support eXecute Only Memory (XOM) - note: it depends on chip's system level design. If you only want to provide firmware protection, and if the firmware is not trusted, it might be better off to leave it in Non-secure world.

    One thing you can do in your case is don't provide direct access to NSC space to your 3rd parties software developers. Being the "owner" of Secure world, you can define the NSC allocation and entry points so that you can ensure all APIs would have proper checks if needed.

    By the way, if you are an RTOS developer, you could have access to our support via our ecosystem program. Please drop me an email directly and I will ask our ecosystem partner manager to follow up.

    regards,
    Joseph

Reply
  • 0 Arm Employee Badge in reply to raghu.ncstate

    In an application use case, if the Non-secure applications are running in NS unprivileged, it means the hacker need to be break into privileged level first, before they can call the Secure API in handler mode. So there need to be two levels of vulnerabilities.
    But of course, I agree that a hacker can also just buy a chip and try to hack the Secure API....

    > If my secure Api does NOT check control_NS and IPSR....
    >If the unprivileged secure API has an exploit....
    First thing is to rethink why those APIs need to be in Secure world? (If you can't trust them to do the checks properly, I don't think I would put them in the Secure memory :-) )

    ARMv8-M also support eXecute Only Memory (XOM) - note: it depends on chip's system level design. If you only want to provide firmware protection, and if the firmware is not trusted, it might be better off to leave it in Non-secure world.

    One thing you can do in your case is don't provide direct access to NSC space to your 3rd parties software developers. Being the "owner" of Secure world, you can define the NSC allocation and entry points so that you can ensure all APIs would have proper checks if needed.

    By the way, if you are an RTOS developer, you could have access to our support via our ecosystem program. Please drop me an email directly and I will ask our ecosystem partner manager to follow up.

    regards,
    Joseph

Children
  • 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! :)
  • 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. :)