Agree to add a topic to the forum and discuss.
As the simplest case we can just provide a configuration switches; but in case there are other requirements on error handling we’d better provide a hook or option based configurations.
@Anton Komlev I think we can at least mention in this weeks’ forum.
/Ken
From: Anton Komlev via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Friday, February 11, 2022 11:04 PM
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [TF-M] Re: halting or rebooting on faults
Hi,
Right. It should be upset to get a reboot after hours of a bug reproduction.
Shall we bring it as a topic to the forum next week to discuss the error handling and its configuration methods?
The best,
Anton
From: Andrej Butok via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Friday, February 11, 2022 1:52 PM
To: Bøe, Sebastian <Sebastian.Boe@nordicsemi.no>
Cc: tf-m@lists.trustedfirmware.org
Subject: [TF-M] Re: halting or rebooting on faults
Agree,
In our TM-M code we have replaced the reset to a loop, to avoid annoying infinite reboots.
Thanks,
Andrej
From: Bøe, Sebastian via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Friday, February 11, 2022 2:44 PM
To: tf-m@lists.trustedfirmware.org
Subject: [TF-M] halting or rebooting on faults
Hi,
it seems we could try to be more consistent with fault handling.
The current default behaviour is:
Error code returned from an SPE function? Reboot.
MemFault/HardFault/SecureFault in the SPE? Halt.
Null-pointer dereference from the NSPE? (results in a secure fault for cortex-m) Halt.
Should we perhaps consistently halt or consistently reboot for these three cases
and allow this to be configurable?
It is not clear to me why an error returned from a function results in a reboot, whereas a Hardfault does not.
They both indicate a fault in the SPE.
At the very least the behaviour should be configurable, which this PR is a step towards: