psa_fwu_accept return new status - PSA_SUCCESS_REBOOT

[benyehez]

In an implementation with a separate booting controller (e.g. privileged access to HW) - it would be helpful if the psa_fwu_accept would allow to indicate the user that a reboot is needed in the system to apply the ACCEPT and enforce the transition of the images to UPDATED.

This is kind of the reciprocation of the psa_fwu_reject.

Can that be included in one of the releases?

[athoelke]

Does the resulting intermediate state of ACCEPTED need to be visible to the update client that calls this API?

For example:

• Is there a use case flow for the update client to 'change their mind' and undo the acceptance?
• In the implementation you describe, is the reboot to complete the transition to UPDATED necessary before the system is able to begin processing a new update request?

If neither of these are true, then it is not clear (to me) that there is a new implementation state that needs to be visible to the update client, and the implementation could hide this behavior from the client without any adverse complications? - unless I have missed another aspect of this use case...

[benyehez]

Thanks for the prompt response!

Exactly - I was indeed referring to the case where the reboot is required to complete the final transition of the image to UPDATED as some other operations may be required by our customers before moving to UPDATE that is tailored to our specific HW even beyond the indications on the image.

I wasn't referring to the client changing their mind scenario - although I agree with you that it may also be a potential justification for providing this capability.

[athoelke]

Can you clarify why it is not possible to implement your use case around the current state model, so that we do not propose an over-engineered addition to the spec? In particular:

1. If other operations are required by a customer prior to accepting the TRIAL and transitioning to UPDATED, why can these not be done before the call to psa_fwu_accept()?
   • Are these operations perhaps only executed as part of a boot sequence, and thus require the reboot as part of the TRIAL →
     UPDATED transition? - if so, what is the reason they are not carried out as part of the reboot that transitioned from STAGED →
     TRIAL state?
2. Is there a realistic scenario where the 'other operations' between the call to psa_fwu_accept() and the restart might fail and result in a need to abandon the update (and requiring the ability to call psa_fu_reject() to transition from ACCEPTED →
   REJECTED state)? - such potentially-failing actions should ideally be carried out prior to psa_fwu_accept() as their failure would naturally lead to calling psa_fwu_reject().
3. Is there a possiblity that the proposed transition from ACCEPTED → UPDATED over a reboot might fail in a way that results in a transition to a different state (rather than remaining in ACCEPTED)?

These details help with writing update client code to be independent of implementation- or component-specific behaviors.

[benyehez]

Sorry for the delayed response.
Those were important questions and I wanted to take this internally to make sure we don't cause major over-complicated spec and remain aligned on the intent of the API.

I'll try to explain our scenario specifically - according to our security officer if a certain version needs to increase its security version number (rollback protection) only a dedicated boot controller has the HW privileged to enforce that. We do allow to run the TRAIL version before actually increasing the security version number (as increasing is a one-time non-recoverable immutable process) This is why we want to pass through the boot again for the psa_fwu_accept.

Our understandings / assumptions on psa_fwu_accept are the following:

1. A call to psa_fwu_accept is allowed to immediately return error (leaving the previous TRAIL versions in TRAIL state)
2. If psa_fwu_accept started it must be terminated eventually with a transition of all TRAIL-->UPDATED versions.
3. No regrets and no transient states. If the process fails in the middle (e.g. version update increase failure/power cycle in the middle of the update, etc...) - we will ensure our implementation retries (i.e. rebooting and retrying) until psa_fwu_accept can be eventually called and return success. If that can't be done (e.g. some HW issue) - the device would be considered a broken device.

Do let me know if these assumptions are breaking the spirit of the psa_fwu_accept API according to the current spec.

Thanks for your consideration.

[athoelke]

Thank you for the detailed requirements in your use case. This approach is very much aligned with the spirit of the current API: psa_fwu_accept() is a commitment from the update client, which cannot be undone.

The described hardware design that makes the monotonic security version number only updatable at boot time does make sense, this mitigates risk of malicious updates to the security version - and as you require, does demand a reboot to take effect.

Although the udpate service could operate as though such a change had been completed prior to reboot, effectively having a write-ahead-log with the new security version, it is also understandable that the system architects might want the change to the security version to be fully persisted prior to accepting a new firmware update. This enables the boot controller to extract the new security version from the accepted firmware image, rather than from some other data store, reducing the risk of a manipulated security version value being used.