-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Async send sigma3 #25695
Async send sigma3 #25695
Conversation
This unblocks the main event loop while performance intensive (e.g. crypto) parts of the process occur.
PR #25695: Size comparison from 346a817 to 52f4a6f Increases (2 builds for cc32xx, mbed)
Full report (2 builds for cc32xx, mbed)
|
This supports locking during SignWithOpKeypair, and other operations that may alter state in the fabric table, while CASESession is performing work in the background during session establishment. CASESession registers as a fabric table listener, and when a fabric is removed (e.g. timeout) it attempts to cancel any outstanding work, and also clears out the fabric index in the work helper data. Therefore, if outstanding work has made it into SignWithOpKeypair, it should be OK until complete. It still relies on other tasks not altering FabricInfo, or the configured OperationalKeystore, but that would have had to have been true before anyways. The mutex was not made recursive. It's omitted from a few functions, which should be OK for now, and there should be cleanup on a subsequent commit (and probably fix up const-ness of member functions, and factoring of API vs. impl functions). This commit is to flush out build/test errors on all CI platforms, and to discuss/review/comment on the general approach.
PR #25695: Size comparison from e2fa6ba to 54586ca Increases above 0.2%:
Increases (4 builds for esp32, linux)
Full report (4 builds for esp32, linux)
|
It's tricky to async background the signing operation, because of the two ways operational signing occurs. Legacy way: opkeypair manually added for fabric info Recommended way: opkeystore handles everything Removed std::mutex because it wasn't supported by all platforms. Instead, made background signing occur only if using the operational keystore (recommended way), since implementors can perform any needed mutual exclusion in the operational keystore. If using manually added operational keypairs (legacy way), keep signing in the foreground, since it's not feasible to mutex the entire fabric table and typically the operations is simpler anyways.
PR #25695: Size comparison from 2ce04b5 to 6b1afb9 Increases above 0.2%:
Increases (1 build for cc32xx)
Full report (1 build for cc32xx)
|
PR #25695: Size comparison from 7a92beb to e719521 Increases above 0.2%:
Increases (1 build for cc32xx)
Full report (1 build for cc32xx)
|
Store only one of data.fabricTable or data.keystore.
PR #25695: Size comparison from 2b3d5c3 to 6479997 Increases above 0.2%:
Increases (1 build for cc32xx)
Full report (1 build for cc32xx)
|
OperationalKeystore declares whether it supports this capability. If so, then CASE session establishment may take advantage of it. If not, then CASE session establishment must use foreground.
PR #25695: Size comparison from b8368a1 to db76a70 Increases above 0.2%:
Increases (1 build for cc32xx)
Full report (1 build for cc32xx)
|
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.
Great work @mlepage-google !
PR #25695: Size comparison from c1108d7 to 7fc0cd6 Increases above 0.2%:
Increases (1 build for cc32xx)
Full report (1 build for cc32xx)
|
Break CASESession::SendSigma3 into smaller substeps
This is the send-side change that corresponds to the handle-side change in #24099.
SendSigma3 is subdivided into smaller substeps (3a, 3b, 3c) so costly work can be done in the background, and not block foreground work.