-
Notifications
You must be signed in to change notification settings - Fork 288
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
Misuse of const in sha256 module #688
Comments
This bug can be test by added these lines anywhere:
The above should not be allowed. Do I understand that the proposed solution is this?
It has a problem though: Tests start failing. Not because any individual test doesn't work, i.e., this passes: |
If the problem is that tests run in parallel, we could either use
Also regarding the atomic ordering, we can probably use |
Yes, that’s what I was thinking. Is OpenSK aiming for any targets without atomics? OpenTitan (for example) doesn’t have atomics but I couldn’t think of an alternative solution. |
It is sometimes possible to use |
Our pragmatic solution for this problem in one case: Use a static mut instead. In this case, |
I don't think it's easy to list all tests that use SHA256. Also increases maintenance. What we could do is disable the BUSY assert with a compiler flag, i.e., |
If the intent of this check is to make sure the library doesn't do parallel hashes, then we shouldn't disable it in tests. We sadly need to use |
We agreed to not use an Atomic, but use a Mutex based implementation that allows to still run tests in parallel. Outside of tests, we will remove this Reasoning is: We want to make sure OpenSK doesn't call SHA256 in parallel, so all hardware crypto implementations can use OpenSK. We don't want to prevent people from using parallel SHA256 in their own code if they know they can support it on their hardware. Therefore, the check will move inside PR coming soon. |
Inside `libraries/opensk`, we want to preserve the property that there are never two SHA256 hashes calculates in parallel. This is useful to support hardware crypto that can't swap out its state. To check this property, there was an assertion in `libraries/crypto`. However, the assertion - didn't work, - should have been in opensk instead - and should run in tests, but not when deployed. Since Rust runs tests in parallel, this PR makes sure that the assertion only fails if two SHA256 are calculated within one thread. Fixes google#688
Inside `libraries/opensk`, we want to preserve the property that there are never two SHA256 hashes calculates in parallel. This is useful to support hardware crypto that can't swap out its state. To check this property, there was an assertion in `libraries/crypto`. However, the assertion - didn't work, - should have been in opensk instead - and should run in tests, but not when deployed. Since Rust runs tests in parallel, this PR makes sure that the assertion only fails if two SHA256 are calculated within one thread. Fixes #688
Expected Behavior
https://github.com/google/OpenSK/blob/develop/libraries/crypto/src/sha256.rs#L28
BUSY
is used for locking the sha256 module betweenSha256::new()
anSha256::finalize()
calls.Actual Behavior
const
in Rust is similar to#define
in C in that its value is copied into its use-sites.Each place
BUSY
is used in this module is an independentCell
and not the same one.I think
static BUSY: AtomicBool
would work here.The text was updated successfully, but these errors were encountered: