Is there a use case for `PSA_ERROR_INSTALL_INTERRUPTED`

[athoelke]

The v0.7 specification states that psa_fwu_install() can return PSA_ERROR_INSTALL_INTERRUPTED if an installation is interrupted or aborted.

There is no definition of what might 'interrupt' an installation. There are already error codes for insufficient power, or other hardware failures that might cause an installation to fail.

The API does not discuss concurrent calls to the API. For example, defining what happens if one thread calls psa_fwu_install(), and before this returns, another thread calls psa_fwu_abort(). The use of this error code seems to assume that such concurrency might be provided by the implementation and required by some applications.

Question

• Is concurrent calls to the API a valid use case for v1.0?

Proposal

Assume that v1.0 implementations do not need to support concurrent calls to the API from multiple threads.

• Remove the PSA_ERROR_INSTALL_INTERRUPTED error code.
• Document that concurrent use of the API is IMPLEMENTATION DEFINED. Implementations are permitted to return an error (such as PSA_ERROR_NOT_PERMITTED) if a concurrent call is detected and not permitted due to an ongoing or overlapping FWU API call.

[bulislaw]

The proposal sounds good to me. I would probably go even stronger and call it "undefined" behaviour rather than implementation defined. While the implementation can do the same in both cases (as illustrated by various c/c++ compilers over the years) it gives clearer signals to the users.

[athoelke]

The trouble with UNDEFINED is that a Client cannot safely do anything, and it proves to be a long-term problem for use cases that might be useful for some systems. Similar to UNPREDICTABLE in Arm architecture which we have slowly replaced with CONSTRAINED UNPREDICTABLE - essentially the implementation can only handle this in a number of pre-defined ways.

I'd want to have the spec state that a Client should not issue concurrent calls to the API unless it knows that this is safe with the implementation. The behavior of the implementation might be one of the following:

• Implicitly safe - the calls to the Service are serialized by the platform/implementation.
• Unsafe - the implementation does nothing to detect or handle concurrent calls. Using concurrent calls could lead to arbitrary behavior.
• Detected and denied by the implementation.
• Detected and conditionally permitted or denied by the implementation. For example, concurrent calls relating to different components might be permitted.

My expectation is that most clients will have no requirement to issue concurrent calls to the API. With the provision of incremental APIs for long-running operations, a Client can manage the interruption of a long-running operation without requiring concurrent calls.