halting or rebooting on faults

List overview All Threads
Download

newer

older

[FYI] Tiny update in level 3...

Security vulnerability notice -...

Bøe, Sebastian

11 Feb 2022 11 Feb '22

1:44 p.m.

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: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/13839

Attachments:

attachment.html (text/html — 3.1 KB)

Show replies by thread

Andrej Butok

11 Feb 11 Feb

1:51 p.m.

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:

https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/13839 https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr ustedfirmware.org%2Fc%2FTF-M%2Ftrusted-firmware-m%2F%2B%2F13839&data=04%7C01 %7Candrey.butok%40nxp.com%7C7ec234046e02411a600808d9ed64a4b6%7C686ea1d3bc2b4 c6fa92cd99c5c301635%7C0%7C0%7C637801838783803687%7CUnknown%7CTWFpbGZsb3d8eyJ WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata =YEimlM9Wj%2F6gPLFMdc%2BXYw6qK%2FC%2FhQwkWJiujAAHfSs%3D&reserved=0

Anton Komlev

3:03 p.m.

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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Friday, February 11, 2022 2:44 PM To: tf-m@lists.trustedfirmware.orgmailto: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: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/13839 https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.trustedfirmware.org%2Fc%2FTF-M%2Ftrusted-firmware-m%2F%2B%2F13839&data=04%7C01%7Candrey.butok%40nxp.com%7C7ec234046e02411a600808d9ed64a4b6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637801838783803687%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=YEimlM9Wj%2F6gPLFMdc%2BXYw6qK%2FC%2FhQwkWJiujAAHfSs%3D&reserved=0

Kevin Townsend

3:05 p.m.

We should definitely make this configurable, at a minimum, yes.

BR, Kevin Townsend

On Fri, 11 Feb 2022 at 16:04, Anton Komlev via TF-M < tf-m@lists.trustedfirmware.org> wrote:

...

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:

https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/13839

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.trustedfirmware.org%2Fc%2FTF-M%2Ftrusted-firmware-m%2F%2B%2F13839&data=04%7C01%7Candrey.butok%40nxp.com%7C7ec234046e02411a600808d9ed64a4b6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637801838783803687%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=YEimlM9Wj%2F6gPLFMdc%2BXYw6qK%2FC%2FhQwkWJiujAAHfSs%3D&reserved=0

TF-M mailing list -- tf-m@lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave@lists.trustedfirmware.org

Ken Liu

14 Feb 14 Feb

3:36 a.m.

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 Komlevmailto:Anton.Komlev@arm.com 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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Friday, February 11, 2022 1:52 PM To: Bøe, Sebastian <Sebastian.Boe@nordicsemi.nomailto:Sebastian.Boe@nordicsemi.no> Cc: tf-m@lists.trustedfirmware.orgmailto: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

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.

811

days inactive

814

days old

tf-m@lists.trustedfirmware.org

4 comments

participants

tags (0)

participants (5)

Andrej Butok
Anton Komlev
Bøe, Sebastian
Ken Liu
Kevin Townsend