Hi Sebastian,
The section in the Platform Security Model is describing the behavior of a system reset – the recommendation is that any preceding runtime state (in volatile memory, or in CPU or peripheral registers) does not influence the execution of the reboot. This is except for an optional suspend or hibernate state, which explicitly maintains runtime state while powering off most or all of the system and will resume via a CPU reset.
System security requirements might require explicit clearing of volatile memory on reset to prevent cold-boot style attacks that could allow an attacker to read any residual RAM contents – although software-based attacks of this kind are partly mitigated by trusted boot, which prevents an attacker from running arbitrary code at reset (unlike devices that boot from untrusted flash memory).
The specific bullet list in the PSA Firmware Framework for M (in §3.5.1 on Panics) is describing the challenges for an implementation that does NOT do the recommended action of resetting the system when a Secure Partition panics, which justifies the recommendation to reset the system. If the SPM does reset the system, then the challenges in that bullet list are avoided. The issues listed are:
- An individual Secure Partition cannot be reset and restarted in isolation.
- A Secure Partition may have state maintained on behalf of clients that will be destroyed when restarting the service. There is no mechanism to re-synchronize the clients.
- It is not possible to determine at the point of panic how much corruption has occurred within the Secure Partition and elsewhere in the SPE.
If the SPM only restarted the Secure Partition that panicked, then any previous runtime state within that Secure Partition is lost, including any ongoing connections with clients of services within that partition, or any resources that those services were managing for their clients. FF-M does not provide a specified mechanism for such clients to be informed that the connections are broken, and there is no way to provide a general strategy that allows a client to recover from a service failure. This is what is meant by “There is no mechanism to re-synchronize the clients.”.
I have just realized that in FF-M 1.1, there may be scenarios in which restarting a Secure Partition could be justified and technically feasible. If a Secure Partition with only Stateless services maintains no client state or resources, and also maintains no connections to other RoT Services (so there are no RoT Services maintaining state for this Secure Partition) – then restarting this Secure Partition might not suffer from the first two complications listed in §3.5.1. The third issue is harder to control: the risks from the data corruption that lead up to the panic depends partly on the SPE isolation policies, and on what this Secure Partition was responsible for. Reset remains the recommended response to a Secure Partition panic in v1.1.0.
Regards,
Andrew Thoelke Arm Ltd.
From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Ken Liu via TF-M Sent: 26 October 2021 10:51 To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] System reset
Hi Sebastian,
The specification writer looks not here these two days, let me try to explain it based on my understanding.
I think two specs both recommend clearing general runtime data while resetting. If the booting runtime clearing code can clear the RAM data for a specific platform, the memory clearing in the 'tfm_spm_hal_system_reset ' can be skipped. Basically, simple hardware reset triggering is just fine.
The special-purpose memory to be retained during resetting is not a generic runtime memory, hence they need to be treated specially, such as putting them in a special bank or region and skipping clearing them during booting. This special region can be treated as a private asset of one service, which could NOT be shared between components for direct access. The owner service provides the functionality around this asset.
Please put more comments or corrections, thanks.
/Ken
From: TF-M mailto:tf-m-bounces@lists.trustedfirmware.org On Behalf Of Sebastian Bøe via TF-M Sent: Monday, October 25, 2021 3:16 PM To: mailto:tf-m@lists.trustedfirmware.org Subject: [TF-M] System reset
Hi,
I would like some clarification about system reset.
There are these two statements about it in the PSM and PSA-FF:
"No run-time state from before the reset should be retained or used, except where necessary if suspend or hibernate are supported, see section 4.6." -- PSM page 22.
"A Secure Partition may have state maintained on behalf of clients that will be destroyed when restarting the service." -- PSA-FF page 47.
Is it the responsibility of tfm_spm_hal_system_reset to destroy this state or is it OK to destroy it after reset as a part of the C runtime startup procedure?
I assume for instance that PRoT .bss is cleared as a part of the C runtime startup procedure, but should it also have been destroyed as a part of tfm_spm_hal_system_reset ?
PSM - Platform Security Model. https://developer.arm.com/documentation/den0128/0100/
PSA-FF PSA Firmware Framework https://armkeil.blob.core.windows.net/developer/Files/pdf/PlatformSecurityAr...
Sebastian Bøe Nordic Semiconductor
Hi,
thank you both for such detailed answers. This makes it very clear that clearing the state is only a recommendation and not a security requirement.
Sebastian Bøe
On Tue, 26 Oct 2021 at 12:40, Andrew Thoelke via TF-M < tf-m@lists.trustedfirmware.org> wrote:
Hi Sebastian,
The section in the Platform Security Model is describing the behavior of a system reset – the recommendation is that any preceding runtime state (in volatile memory, or in CPU or peripheral registers) does not influence the execution of the reboot. This is except for an optional suspend or hibernate state, which explicitly maintains runtime state while powering off most or all of the system and will resume via a CPU reset.
System security requirements might require explicit clearing of volatile memory on reset to prevent cold-boot style attacks that could allow an attacker to read any residual RAM contents – although software-based attacks of this kind are partly mitigated by trusted boot, which prevents an attacker from running arbitrary code at reset (unlike devices that boot from untrusted flash memory).
The specific bullet list in the PSA Firmware Framework for M (in §3.5.1 on Panics) is describing the challenges for an implementation that does NOT do the recommended action of resetting the system when a Secure Partition panics, which justifies the recommendation to reset the system. If the SPM does reset the system, then the challenges in that bullet list are avoided. The issues listed are:
- An individual Secure Partition cannot be reset and restarted in
isolation.
- A Secure Partition may have state maintained on behalf of clients that
will be destroyed when restarting the service. There is no mechanism to re-synchronize the clients.
- It is not possible to determine at the point of panic how much
corruption has occurred within the Secure Partition and elsewhere in the SPE.
If the SPM only restarted the Secure Partition that panicked, then any previous runtime state within that Secure Partition is lost, including any ongoing connections with clients of services within that partition, or any resources that those services were managing for their clients. FF-M does not provide a specified mechanism for such clients to be informed that the connections are broken, and there is no way to provide a general strategy that allows a client to recover from a service failure. This is what is meant by “There is no mechanism to re-synchronize the clients.”.
I have just realized that in FF-M 1.1, there may be scenarios in which restarting a Secure Partition could be justified and technically feasible. If a Secure Partition with only Stateless services maintains no client state or resources, and also maintains no connections to other RoT Services (so there are no RoT Services maintaining state for this Secure Partition) – then restarting this Secure Partition might not suffer from the first two complications listed in §3.5.1. The third issue is harder to control: the risks from the data corruption that lead up to the panic depends partly on the SPE isolation policies, and on what this Secure Partition was responsible for. Reset remains the recommended response to a Secure Partition panic in v1.1.0.
Regards,
Andrew Thoelke Arm Ltd.
From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Ken Liu via TF-M Sent: 26 October 2021 10:51 To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] System reset
Hi Sebastian,
The specification writer looks not here these two days, let me try to explain it based on my understanding.
I think two specs both recommend clearing general runtime data while resetting. If the booting runtime clearing code can clear the RAM data for a specific platform, the memory clearing in the 'tfm_spm_hal_system_reset ' can be skipped. Basically, simple hardware reset triggering is just fine.
The special-purpose memory to be retained during resetting is not a generic runtime memory, hence they need to be treated specially, such as putting them in a special bank or region and skipping clearing them during booting. This special region can be treated as a private asset of one service, which could NOT be shared between components for direct access. The owner service provides the functionality around this asset.
Please put more comments or corrections, thanks.
/Ken
From: TF-M mailto:tf-m-bounces@lists.trustedfirmware.org On Behalf Of Sebastian Bøe via TF-M Sent: Monday, October 25, 2021 3:16 PM To: mailto:tf-m@lists.trustedfirmware.org Subject: [TF-M] System reset
Hi,
I would like some clarification about system reset.
There are these two statements about it in the PSM and PSA-FF:
"No run-time state from before the reset should be retained or used, except where necessary if suspend or hibernate are supported, see section 4.6." -- PSM page 22.
"A Secure Partition may have state maintained on behalf of clients that will be destroyed when restarting the service." -- PSA-FF page 47.
Is it the responsibility of tfm_spm_hal_system_reset to destroy this state or is it OK to destroy it after reset as a part of the C runtime startup procedure?
I assume for instance that PRoT .bss is cleared as a part of the C runtime startup procedure, but should it also have been destroyed as a part of tfm_spm_hal_system_reset ?
PSM - Platform Security Model. https://developer.arm.com/documentation/den0128/0100/
PSA-FF PSA Firmware Framework
https://armkeil.blob.core.windows.net/developer/Files/pdf/PlatformSecurityAr...
Sebastian Bøe Nordic Semiconductor -- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m
tf-m@lists.trustedfirmware.org
-
Andrew Thoelke -
Sebastian Bøe