-
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
Implement PSA interruptible sign/verify hash #6737
Implement PSA interruptible sign/verify hash #6737
Conversation
764e7b0
to
2e34ee4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've done a design review, not a code review.
Regarding test coverage, the test plan sketch in the issue description might be ok, but it's so lacking details that it's hard to tell what you have in mind. I've added my reflections in comments in the .function file.
Regarding the library, there are major design issues which I think need to be addressed before reviewing. Regarding the conversion to ASN.1, let's not move the code from pk, we really shouldn't be using it. It will be a lot easier to start with a clean history that doesn't move this code back and forth. Regarding compilation guards, we can defer part of the work, but it might make it hard to pass the CI, and even if it passes the CI now it risks hurting driver work so we need to be reasonably clean. Regarding driver support, we can skip it for now as long as what we do doesn't hurt driver support.
7cdcd75
to
abf669f
Compare
5949478
to
8f5b8ad
Compare
Signed-off-by: Paul Elliott <[email protected]>
Signed-off-by: Paul Elliott <[email protected]>
8f5b8ad
to
d0ec69d
Compare
Signed-off-by: Paul Elliott <[email protected]>
Signed-off-by: Paul Elliott <[email protected]>
Using PSA interruptible interfaces will cause previously set values to be overwritten. Signed-off-by: Paul Elliott <[email protected]>
Signed-off-by: Paul Elliott <[email protected]>
Signed-off-by: Paul Elliott <[email protected]>
Signed-off-by: Paul Elliott <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've completed my review, including the new commits, and checked that the feedback from my first review had all been addressed.
I've not found any blockers beyond those raised by Gilles.
Still on my TODO list:
- compare API in this PR to that in the API PR;
- review lcov results.
*min_completes = 1; | ||
|
||
*max_completes = PSA_INTERRUPTIBLE_MAX_OPS_UNLIMITED; | ||
} else |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[non-blocker] Hmm, shouldn't that be else if( max_ops == PSA_INTERRUPTIBLE_MAX_OPS_UNLIMITED )
? The function seems to have an undocumented assumption that max_ops
will be either unlimited or 0 or 1.
Actually I'd like to suggest an alternative way to structure the function: start with
*min_completes = 1;
*max_completes = PSA_INTERRUPTIBLE_MAX_OPS_UNLIMITED;
Then handle the cases where we can say something better about one of those bounds (one case for min = 2, one case for max = 1).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be changing it back to the way it was prior to extracting it into the function, which Gilles previously wasn't happy with. Github is hiding these conversations from me, so its difficult to refer back to it here, unfortunately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, big PRs are intrinsically hard to review, but github is really not making it any easier by hiding stuff like this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm guessing you're refering to this?
I was objecting to
if( max_ops == PSA_INTERRUPTIBLE_MAX_OPS_UNLIMITED )
{
min_completes = 1;
max_completes = 1;
}
else
{
min_completes = 2;
max_completes = PSA_INTERRUPTIBLE_MAX_OPS_UNLIMITED;
}
Specifically, setting min_completes = 2
whenever max_ops
is finite.
I agree with Manuel that max_completes
should be 1 only when max_ops
is UNLIMITED.
But now that we have the code in one place, I won't insist on it: it's easy to fix later, and reasonably easy to discover.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is my review of lcov results. It looks like there is a few more cases we could and IMO should test, but I don't think any is a blocker, and they can be left for later if tracked.
Note: I've compare the API against #6279 and found all the changes to be good. Also, I've checked that all my comments there had been addressed. @gilles-peskine-arm do you want to check that all your comments on #6279 have been addressed here or are you happy to leave that for later? (I've complete my review, and do not intend to to any more review until something new is pushed.) |
I believe this is ready for final review now - all blockers have been addressed, and all non-blockers filed as issues. CI is green, and I have a code-styled and rebased branch ready to go. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately I found one problem in the latest batch of commits.
Other than that I'm happy with this PR.
Previously calling get_num_ops more than once would have ended up with ops getting double counted, and not calling inbetween completes would have ended up with ops getting missed. Fix this by moving this to where the work is actually done, and add tests for double calls to get_num_ops(). Signed-off-by: Paul Elliott <[email protected]>
Hopefully final changes before re-code-style / rebase. Ready for review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Note (since a rebase is coming): the commit I approved is 34c61f4
I rebased and restyled my copy so that I can compare when the same is done with this PR, here are my notes:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
The rebase and restyle is being maintained in #7095 - I can either push that here, or we can review / merge that - wdyt @gilles-peskine-arm and @mpg? Also are we still waiting for @athoelke to review? |
Whichever you prefer. |
If we're happy with 7095 let's merge that: this will save one round of waiting for the CI. |
Superseded by #7095 which is the same semantic content, but rebased and restyled. |
Description
Implement PSA interruptible sign/verify hash, using the internal restartable ECDSA sign / verify interface. Addresses #6332.
Design based on #6279 as of its first commit 0cb0972 . Some requested changes there have been made to this version.
Missing: PSA_WANT guards around the code to remove if functions are not compiled in. I will definitely need some help with this, so this will have to wait until. the new year. I do not believe this prevents review of the rest though, and I hope this will not prove a major amount of work.
Gatekeeper checklist
or not requireddone, ornot requiredor not required