ARM-software
cmse: enable SAU defines for non-secure state
The SAU register defines and bitfields are still useful for applications that are not running in the secure state.
e.g. An application triggers a SecureFault, during which the secure handler preserved the SFSR register value in .noinit memory. Once rebooted, the non-secure application queries the SFSR register and wishes to inspect the bits to determine more precisely the cause.
@JordanYates, sorry for the delay. We discussed this use cases and our security experts doesn't consider this approach desirable from security point of view.
One should generally not expose raw information from secure state to non-secure state for processing. Instead, the required processing should be done in secure firmware. The secure firmware can expose required (and considerably non-security related) information to the non-secure side explicitly by using a distinct interface.
One should generally not expose raw information from secure state to non-secure state for processing
The non-secure state is the state that has communications capabilities (IP, Bluetooth, etc) to send fault reasons to developers so that they can be fixed. Knowing that a secure fault occurred has very little value for debugging unless it is also associated with an address at which it occurred, and ideally what sort of secure fault it was. These two pieces of information are contained in the SFAR and SFSR registers.
Instead, the required processing should be done in secure firmware
What do you define as required processing?
The secure firmware can expose required (and considerably non-security related) information to the non-secure side explicitly by using a distinct interface.
I would consider the SFAR and SFSR registers to be "required information" in terms of debugging. Why is it problematic for the non-secure side to know whether the fault was due to lazy preservation of floating-point state, vs any other reason.
What form do you suggest processing the SFAR and SFSR register contents into?
It would be useful to have an idea of what your security experts would consider a good interface for communicating secure fault causes back to the non-secure domain.
To be explicit, Trusted-Firmware-M has functionality for retrieving exception information inside the secure fault handler, added explicitly for the purpose of saving that information for later analysis. This contains the SFAR and SFSR registers. This certainly implies that the information (struct exception_info_t) is supposed to be sent to the non-secure side, it's no use to anyone if it never leaves the secure domain.
Hi @JordanYates ,
maybe you can take a look at CMSIS-View pack that offers Fault component for recording and analyzing of faults on Cortex devices.
There is also an example for Trust-Zone device (STMicroelectronics B-U585I-IOT02A board) with documentation.
That example shows fault analysis also of secure-state faults.
There is also an example for Trust-Zone device (STMicroelectronics B-U585I-IOT02A board) with documentation.
Thank you for this example, it exactly proves my point why this PR is needed.
The non-secure code in the example is copy-pasting the definitions, as they are not available from the common header.
https://github.com/ARM-software/CMSIS-View/blob/2ea4c9175677469ea20125f2d0910bd348b21992/Examples/Fault/B-U585I-IOT02A/NonSecure/ARM_FaultPrint.c#L29-L54
@JordanYates, I am still not convinced that exposing all SAU defines regardless of target security state is the correct and clean approach.
I am not a security expert and can't judge what sensitive information could get exposed inadvertently by passing raw content of security state registers to non-secure state.
I am not a security expert and can't judge what sensitive information could get exposed inadvertently by passing raw content of security state registers to non-secure state.
This PR changes nothing with regards to passing raw content to the non-secure state. It is possible now, it would be possible after, it will always be possible. It is simply whether the definitions are available to the non-secure code.
Once the register contents hit the non-secure side, hiding the definition provides nothing with respect to security, since the non-secure side can either:
- Copy paste definitions (as the ARM sample code does)
- Send the register remotely to be decoded by some other service
I am still not convinced that exposing all SAU defines regardless of target security state is the correct and clean approach.
Then please suggest the subset that would be acceptable. If it is not acceptable to expose any of these defines for some reason, I would love to see the sample code updated to remove the copy paste (since it is apparently a security risk and not acceptable) without losing the functionality.