Edit: CONTROL.nPRIV is actually banked so I modified my question
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:
Am I correct? If so is it not an issue?
> Based on the ARMv8M-ARM, CONTROL_* does not control > whether the processor is in privileged or unprivileged > mode right ? It only specifies if the processor, when > running in thread mode, has privileged access or not. Yes, that's correct. >I haven't been able to find a bit or mode in any > control register, that determines if the processor > is in thread or handler mode. Please use IPSR. >if CONTROL_NS==1 and CONTROL_S==1, and processor > is in handler mode. Yes, if the Secure API is called it will be Secure privileged as it is handler mode. But you can add checks at starting of API if you won't want it to be execute in privileged. > mentioned I could check CONTROL_NS and IPSR to determine > NS caller state, but these registers can only be read > in privileged mode and reading it in thread/unprivileged > mode on the secure side during the beginning of the > secure API will result in a fault. That's incorrect. If you are in Secure unprivileged you will read 0 for CONTROL_NS and IPSR, no fault exception. So you can add check to ensure Secure API is unprivileged. regards, Joseph
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