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

Add locking around key handle operations in mbed provider #41

Merged
merged 2 commits into from
Oct 16, 2019

Conversation

ionut-arm
Copy link
Member

Add a mutex around create, open and close key operations.
Add a semaphore to wrap all function call that use keys.

Fixes #40

@ionut-arm ionut-arm added the bug Something isn't working label Oct 15, 2019
@ionut-arm ionut-arm self-assigned this Oct 15, 2019
@@ -56,13 +57,17 @@ const SUPPORTED_OPCODES: [Opcode; 7] = [
Opcode::ListOpcodes,
];

const KEY_SLOT_COUNT: isize = 32;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a way to read that value from the FFI?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or maybe put it in the constants file instead?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not through FFI, as it is not directly exposed in the header files, but I added it in the constants file.

pub struct MbedProvider {
// When calling write on a reference of key_id_store, a type
// std::sync::RwLockWriteGuard<dyn ManageKeyIDs + Send + Sync> is returned. We need to use the
// dereference operator (*) to access the inner type dyn ManageKeyIDs + Send + Sync and then
// reference it to match with the method prototypes.
key_id_store: Arc<RwLock<dyn ManageKeyIDs + Send + Sync>>,
local_ids: RwLock<LocalIdStore>,
key_handle_mutex: Mutex<()>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it would be nice to add a comment on top of those lines to explain why the Mutex, Semaphore are needed. Just as an help for future code readers.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@hug-dev
Copy link
Member

hug-dev commented Oct 15, 2019

It would be nice, prior to this PR, to make another one that adds the stress test to the CI (and the all.sh script) to see that it fails and check that this one fixes it.

This commit adds locking around the operations that deal with
allocating or closing key handles in the mbed provider. Said calls
are not thread safe, so a mutex protects access to the calls and
a semaphore limits the number of threads that can hold key slots.

Change-Id: Icbcad5c05179275d2138d830b33e43976329e931
Signed-off-by: Ionut Mihalcea <[email protected]>
Copy link
Member

@hug-dev hug-dev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the change 👍

@ionut-arm ionut-arm merged commit 3cad90c into parallaxsecond:master Oct 16, 2019
@ionut-arm ionut-arm deleted the locks branch October 16, 2019 09:49
@hug-dev hug-dev mentioned this pull request Jun 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Key handle manipulation is not thread-safe in Mbed Crypto
2 participants