-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
PSA Interruptible operations need guarding with PSA_WANT defines #7029
Comments
For me, this means this task is unlikely to be an S, so I'm taking the liberty of re-labeling to M. Please let me know if you disagree! |
Actually, I doubt that we need this level of granularity. I propose to make it simpler: a single |
No, this isn't right. We do want to allow builds where the API functions exist but the implementation doesn't do interruptibility, for applications that are using the interruptible functions for portability and that are compiled for a platform that doesn't do interruptibility for code size or attack surface. |
It would certainly be useful to scope out the interruptible PSA_WANT defines here - the uncertainty of what is required is part of the reason this has not been done.
Other than setting the number of ops per operation to bethe max value, we don't really have this functionality, though. Is it worth complicating this for something we don't have yet? As you say, a single define would be simple, a raft of defines somewhat more difficult, especially if we have to agree on what these defines are to start with. Could we start out with what you proposed, and go from there later? |
The configuration interface is a user-facing interface, so we need to decide before 4.0.
I'm leaning towards not having a raft of defines. I'd initially thought we would need to have separate defines per mechanism, but on second thoughts, I think we don't need that in the API (
So the code structure would be something like this:
|
Design decision: we do want a general For the time being, we continue having the iop functions always built, like the other API functions. Applications that don't use the functions should do link-time dead code elimination. |
I took the liberty to slightly modify the title because guards are now required also for interruptible key generation, not only signing. |
From Gilles:
From further discussion with Gilles, although he is happy for this to go in a seperate PR, there are some discussions yet to be had about the granularity of PSA_WANT defines required. I need to check with him if we can just go with blanket cover for now, and add granularity later.
Edit (from @valeriosetti): while at this, please fix also #9651 (comment)
The text was updated successfully, but these errors were encountered: