PSA setup functions should leave the object unchanged on failure #855

New issue

Open

opened 2026-07-30 06:30:11 -05:00 by gilles-peskine-arm · 2 comments

gilles-peskine-arm commented

2026-07-30 06:30:11 -05:00

(Migrated from github.com)

If psa_xxx_setup() fails, according to the PSA Crypto specification, it must leave the operation object unchanged. This requirement was added in version 1.1 of the specification to all setup functions.

Our implementation does not obey this constraint: if you call psa_hash_setup() on an active object, it calls psa_hash_abort() before returning PSA_ERROR_BAD_STATE. Most if not all other setup functions have the same non-compliance.

(For a previously inactive object, calling psa_xxx_abort() on error is the right thing: it returns the object to an inactive state.)

If `psa_xxx_setup()` fails, according to the PSA Crypto specification, it must leave the operation object unchanged. This requirement was added in [version 1.1 of the specification](https://arm-software.github.io/psa-api/crypto/1.1/api/ops/hashes.html#c.psa_hash_setup) to all setup functions. Our implementation does not obey this constraint: if you call `psa_hash_setup()` on an active object, it calls `psa_hash_abort()` before returning `PSA_ERROR_BAD_STATE`. Most if not all other setup functions have the same non-compliance. (For a previously inactive object, calling `psa_xxx_abort()` on error is the right thing: it returns the object to an inactive state.)

umbra3l commented

2026-08-04 01:15:17 -05:00

(Migrated from github.com)

Hi! I'd like to work on this as my first open-source contribution. I think I understand the issue.
Would it be okay if I take this on? If so, please assign me.

Hi! I'd like to work on this as my first open-source contribution. I think I understand the issue. Would it be okay if I take this on? If so, please assign me.

davidhorstmann-arm commented

2026-08-27 11:38:00 -05:00

(Migrated from github.com)

@umbra3l Thanks for the offer and apologies for the lateness of response.

If you still have time to have a go at this, you're very welcome to give it a go! We'd be looking for a PR for each multipart interface containing:

A non-regression test that creates an active object and calls _setup() on it before checking that it is unchanged.
A fix for the problem so that the test passes.

It might be best to start with a PR for a single interface (e.g. psa_hash_setup()) and see how that goes first.

Let us know if that sounds okay.

@umbra3l Thanks for the offer and apologies for the lateness of response. If you still have time to have a go at this, you're very welcome to give it a go! We'd be looking for a PR for each multipart interface containing: * A non-regression test that creates an active object and calls `_setup()` on it before checking that it is unchanged. * A fix for the problem so that the test passes. It might be best to start with a PR for a single interface (e.g. `psa_hash_setup()`) and see how that goes first. Let us know if that sounds okay.

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gh-Mbed-TLS/TF-PSA-Crypto#855

No description provided.

Rows
Columns