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

Extend operation state quirk to cover all operation state operations. #327

Closed
simo5 opened this issue Dec 18, 2023 · 4 comments · Fixed by #378
Closed

Extend operation state quirk to cover all operation state operations. #327

simo5 opened this issue Dec 18, 2023 · 4 comments · Fixed by #378
Labels
enhancement New feature or request

Comments

@simo5
Copy link
Member

simo5 commented Dec 18, 2023

PR #324 introduced the ability to set a configuration quirk so that trying to save the state is not even attempted.

This should be extended to all uses of the operation state function.
Ideally by checking for the quirk within the body of the operation state wrapper itself.

@simo5 simo5 added the enhancement New feature or request label Dec 18, 2023
@simo5
Copy link
Member Author

simo5 commented Dec 18, 2023

@sahanaprasad07 can you pick this one up in the future?

@sahanaprasad07
Copy link
Contributor

Hi @simo5 , which other operation state do you mean here? GetOperationState is only called in signature.c and digests.c. Operate state quirk seems to be covered in both these places already.

@simo5
Copy link
Member Author

simo5 commented Jan 8, 2024

I think the switch should be checked within the GetOperationState interface function, instead of checking for it in all the places where it is called.

So it is a matter of special casing this function like I did here:

CK_RV side_channel_free_Decrypt(P11PROV_CTX *ctx, CK_SESSION_HANDLE hSession,
for the Decrypt interface.

The only difference is that we completely replace the auto-generated "Get/SetOperationState" functions from interface.pre instead of just adding a special case.

@simo5
Copy link
Member Author

simo5 commented Jan 8, 2024

Or maybe we find a generic way to block any function call and add the same code to all, it could be done with a bitfield store on the provider context and then have a generic check in the autogenerated functions.
Most functions would never be blocked but this would allow us to selectively block calls which could be used in testing as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants