Allow NS HardFault to be handled by NS code

[c1728p9]

Description

Set the BFHFNMINS bit of the AIRCR to 1 on secure boot so non-secure code can handle its own hard faults. This enables mbed-os to performs recovery operations on crashes along with hooking the HardFault handler for testing.

Pull request type

[ ] Fix
[ ] Refactor
[ ] Target update
[x] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

[deepikabhavnani]

@c1728p9 Cmse_lib.o should be added as well.

@ARMmbed/mbed-os-maintainers - Changes in secure side should come in minor release or patch release ?

CC @ARMmbed/team-nuvoton

@gaborkertesz FYI, This might be a requirement for upcoming features in Mbed OS.

[c1728p9]

Event though I rebuilt cmse_lib.o, was an identical binary so there is no diff for it.

[wmnt]

If Arm-v8M security extension is to be used for secure/non-secure isolation, this bit must not be set to 1.
This bit was introduced for use cases when the user does not require secure execution and wants a single security state in the core. Please reach out for further details if needed.

[wmnt]

To elaborate further: keeping BFHFNMINS at 0 is a requirement for secure execution from the Arm-v8M security extension hardware architecture point of view in Trusted Firmware M.
Setting this bit to 1 would enable elevation of privilege threats whereby NS fault handlers gain higher privilege than secure fault handlers, introducing a major vulnerability. It e.g. allows NS fault handlers to manipulate syndrome information associated with security violations before the secure fault handler is executed, leading e.g. to repudiation attacks.

[kjbracey]

Not totally following the BFHFNMINS=1 objections - I'm not that familiar with the architecture, but seems to me to be far more heavily engineered for correct operation in that mode than these comments suggest:

• "use cases when the user does not require secure execution and wants a single security state in the core" - then why all the proper prioritisation and distinction between of secure and non-secure HardFaults?
• "NS fault handlers to manipulate ... before the secure fault handler is executed" - the secure fault handler is always secure

Certainly there are setups where the secure side may be needing these exceptions - eg if the main OS is secure - but we're talking here about a non-secure OS calling secure subroutines, aren't we? And system death/reboot (or recovery) in the non-secure OS side on failure?

Anyway, if BFHFNMINS is set to 0, the secure code would get in the way less if you could avoid hitting the HardFault or BusFault in the first place. Mainly it arises as an escalation, many of which could be avoided by:

• enabling MemManage and UsageFault exceptions - they always have secure and non-secure versions
• making ROM read-only so you get MemManage not BusFault when you write to NULL

(both assuming Main Extension, which Cortex-M33 has)

Also, if the secure code is having BFHFNMINS=0, then it really should be providing an alternative non-secure interrupt to report BusFaults and HardFaults to the non-secure code, once it's finished doing whatever it needs to do. We need to be able to reach mbed_fault_handler() somehow - either BFHFNMINS=1, or this alternative interrupt.

[c1728p9]

@kjbracey-arm the target this change was made for is the M2351 which is an M23 and doesn't have Main Extension. Enabling the MemManage fault was what I tried initially, but it didn't help as this device doesn't support it.

[c1728p9]

Closing this due to its security implications.