Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add interruptible key generation PSA APIs #9528

Conversation

waleed-elmelegy-arm
Copy link
Contributor

@waleed-elmelegy-arm waleed-elmelegy-arm commented Sep 2, 2024

Description

fixes #9106
Add interruptible key generation PSA APIs.

PR checklist

Please remove the segment/s on either side of the | symbol as appropriate, and add any relevant link/s to the end of the line.
If the provided content is part of the present PR remove the # symbol.

  • changelog provided
  • development PR provided
  • framework PR not required
  • 3.6 PR not required because: new feature
  • 2.28 PR not required because: new feature
  • tests provided

Notes for the submitter

Please refer to the contributing guidelines, especially the
checklist for PR contributors.

Help make review efficient:

  • Multiple simple commits
    • please structure your PR into a series of small commits, each of which does one thing
  • Avoid force-push
    • please do not force-push to update your PR - just add new commit(s)
  • See our Guidelines for Contributors for more details about the review process.

@waleed-elmelegy-arm waleed-elmelegy-arm force-pushed the add-iop-key-gen branch 3 times, most recently from 98d17bd to 3f2662c Compare September 9, 2024 10:26
@waleed-elmelegy-arm waleed-elmelegy-arm changed the title Add interruptible key generations PSA APIs Add interruptible key generation PSA APIs Sep 9, 2024
@waleed-elmelegy-arm waleed-elmelegy-arm force-pushed the add-iop-key-gen branch 6 times, most recently from 784162f to dc088e8 Compare September 10, 2024 15:33
@waleed-elmelegy-arm waleed-elmelegy-arm added needs-review Every commit must be reviewed by at least two team members, needs-reviewer This PR needs someone to pick it up for review size-m Estimated task size: medium (~1w) component-psa PSA keystore/dispatch layer (storage, drivers, …) and removed DO-NOT-MERGE labels Sep 10, 2024
@waleed-elmelegy-arm
Copy link
Contributor Author

ABI CI failure is expected.

Copy link
Member

@paul-elliott-arm paul-elliott-arm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First round - looks reasonably sound, other than comments - however, do we not need to regenerate psa_sim_crypto_client.c and psa_sim_crypto_server.c ?

type = psa_get_key_type(attributes);

if (!PSA_KEY_TYPE_IS_ECC(type)) {
operation->error_occurred = 1;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here and other places: We need to call abort internally if any error occurs, but not clean up the num_ops or error_occurred flags, to further protect against accidental operation re-use.

*
* \retval #PSA_SUCCESS
* The operation started successfully - call \c mbedtls_psa_generate_key_complete()
* with the same context to complete the operation.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are not referring to it as a context anywhere else, in crypto.h we referred to it as an operation object rather than a context.

/* Make the struct non-empty if algs not supported. */
unsigned MBEDTLS_PRIVATE(dummy);
#endif
} mbedtls_psa_generate_key_iop_operation_t;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be mbedtls_psa_generate_key_iop_t? I see where you are coming from, but the double 'operation' seems clumsy, and we didn't use it for the other structures.

} mbedtls_psa_generate_key_iop_operation_t;

#if defined(MBEDTLS_ECP_C)
#define MBEDTLS_PSA_KEY_AGREEMENT_INTERRUPTIBLE_OPERATION_INIT { { 0 }, 0 }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as above, we could just use MBEDTLS_PSA_KEY_AGREEMENT_IOP_INIT() here

* interface specification for transparent drivers.
*
* \param[in] operation The \c mbedtls_psa_generate_key_iop_operation_t to use.
* This must be initialized first.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... and have had setup called on the same operation object.

* \param[in] operation The \c mbedtls_psa_generate_key_iop_operation_t to use.
* This must be initialized first.
* \return Total number of operations.
*/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here and others: I know these are not technically doing anything interruptible, but I'm unsure we should be leaving the _iop_ out of the function names. Its an interruptible style set of operations, it feels confusing to not name it in the same way.

* interface specification for transparent drivers.
*
* \param[in] operation The \c mbedtls_psa_generate_key_iop_operation_t to abort.
* This must be initialized first.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aborting an uninitialised operation object should be fine, it doesn't need to be initialised first.

@@ -0,0 +1,4 @@
Features
* Add new psa key agreements APIs to generate private key
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreement, not agreements I think.

Also to generate a private key

@gilles-peskine-arm
Copy link
Contributor

Based on my experience with #9490, this is too large. Please split it into manageable pull requests.

As a rule of thumb, we should never have size-m pull requests. A size-m issue should be done in several increments.

@paul-elliott-arm
Copy link
Member

Based on my experience with #9490, this is too large. Please split it into manageable pull requests.

As a rule of thumb, we should never have size-m pull requests. A size-m issue should be done in several increments.

I agree this is a relatively large PR, but as with all of these interfaces, it is well nigh impossible to split things down any finer, whilst still having any tests at all. The individual functions do not stand on their own, and without testing, we should not be merging the PR. This is why we split into functionality and sanity testing / negative and further testing, I'm really not sure how we would go any finer than this whilst having a meaningful PR.

@gilles-peskine-arm gilles-peskine-arm added the priority-high High priority - will be reviewed soon label Oct 28, 2024
@waleed-elmelegy-arm
Copy link
Contributor Author

Done in:
#9639
#9651
#9665

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component-psa PSA keystore/dispatch layer (storage, drivers, …) needs-review Every commit must be reviewed by at least two team members, needs-reviewer This PR needs someone to pick it up for review priority-high High priority - will be reviewed soon size-m Estimated task size: medium (~1w)
Development

Successfully merging this pull request may close these issues.

Implement Interruptible ECC Keypair Generation
3 participants