-
Notifications
You must be signed in to change notification settings - Fork 71
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 new parsec provider using ATECCx08 cryptochip via CryptoAuthentication Library #303
Add new parsec provider using ATECCx08 cryptochip via CryptoAuthentication Library #303
Conversation
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 only had a brief look, but it seems good overall, left just one comment below
config.toml
Outdated
|
||
[[provider]] | ||
provider_type = "CryptoAuthLib" | ||
key_info_manager = "on-disk-manager" |
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 one isn't really needed like this since this file is mostly an example/for documentation purposes, it's not used anywhere. You can comment them out and add some documentation comments like for PKCS11 or TPM above.
For actually running the service we generally do cargo run --features ... -- -c e2e_tests/provider_cfg/.../config.toml
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.
Thank you. I will do it.
Thanks for raising the PR - it's really exciting to see this stuff starting to arrive! And this is a perfectly-sized first change as well - just introducing the provider without its functions. Before we can merge this in, I think we'll need to work a bit more on getting the dependency graph consistent. The CI actions are failing in this PR, and I think it's because there is a lack of consistency between how Confusing, I know! The good news is that I think we can resolve the confusion quite easily by following some basic process. I think we need to create tagged releases of everything in the dependency chain, and then consume those releases in the If we merge this PR as it is, it will cause the CI to fail, so it's worth sorting out ahead of time. Starting from the ground up, and taking into account our Slack conversation as well as this PR. My proposal would be as follows, although I would also like to take advice on this from other engineers in the community, since I haven't been involved with the tagging/releasing process to date, and I want to make sure that what I'm proposing here is consistent with established practice.
This should result in a cleanly-updated and consistent dependency graph, with everything consuming official versions rather than referencing commit hashes or head revisions. Referencing head revisions is a particular problem because it could mean that commits to other repos could actually randomly break things. |
Yes, I fully agree, I was writing very similar proposal in PR top comment. |
I'm not sure how the tagging process links with crates.io. Let me put out a query on the community channel and we'll find out. Ideally the process would be written up somewhere. |
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.
As discussed in the PR and on the Slack channel, we will need to sanitise the dependency graph a little before this can be merged. We are working on a process for this, but it will involve a few PRs and releases in other repos, so please be patient while these propagate through.
I have just pushed a newer version with updated dependencies version numbers as well as corrected config.toml contents as requested by Ionuț. |
a75083a
to
386dcae
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.
Thanks for the PR 🚀!
Added a few comments, overall this looks good to me to start with!
You might have to fix some lints on the CI to make it work...
About the issues you had, I guess they would be fixed by now? The e2e-tests
crate use a git
dependency on the Rust client (at master
) which now contains the newest interface.
src/providers/cryptoauthlib/mod.rs
Outdated
@@ -0,0 +1,89 @@ | |||
// Copyright 2019 Contributors to the Parsec project. |
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.
Let's not dwell on the past, I guess this should be 2021 now 😉
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.
Updated.
// Assigned UUID for this provider: b8ba81e2-e9f7-4bdd-b096-a29d0019960c | ||
uuid: Uuid::parse_str("b8ba81e2-e9f7-4bdd-b096-a29d0019960c").or(Err(ResponseStatus::InvalidEncoding))?, | ||
description: String::from("User space hardware provider, utilizing MicrochipTech CryptoAuthentication Library for ATECCx08 chips"), | ||
vendor: String::from("Arm"), |
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.
Maybe the vendor could be "Microchip Technology "
?
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.
As already mentioned on slack - this is a political decision at the moment it is safe to use "Arm" as a vendor.
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.
Ok agree!
config.toml
Outdated
# (Required) ATCA device type. | ||
# Supported values: "atecc508a", "atecc608a" | ||
#device_type = "atecc508a" | ||
# (Required) Interface for ATCA device | ||
# Supported values: "i2c" | ||
#iface_type = "i2c" | ||
# (Required) Default wake delay for ATCA device | ||
#wake_delay = 1500 | ||
# (Required) Default number of rx retries for ATCA device | ||
#rx_retries = 20 | ||
# (Optional - required for i2c) i2c slave addres | ||
#slave_address = 0xc0 | ||
# (Optional - required for i2c) i2c bus number | ||
#bus = 1 | ||
# (Optional - required for i2c) i2c bus baud rate | ||
#baud = 400000 |
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.
Since for this PR only the key_info_manager
field is required, you could remove that for now and add it later on!
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.
Removed
386dcae
to
c95818d
Compare
} | ||
} | ||
|
||
impl Provide for Provider { |
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.
It looks like the list_keys
test is failing because it attempts to list the keys for all providers in the service - thus, including yours because you've added it in the configuration - and that tries to call list_keys
on this provider, which fails because it uses the default implementation. I think you can just implement it to always return an empty list for now
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.
Thank you for the hint. I can reproduce this (it just failed for me the same way) so I can proceed.
…ation Library. Definition of new structures and their interfaces. Signed-off-by: Robert Drazkowski <Robert.Drazkowski@globallogic.com>
…s requested by a commenter. Signed-off-by: Robert Drazkowski <Robert.Drazkowski@globallogic.com>
Signed-off-by: Robert Drazkowski <Robert.Drazkowski@globallogic.com>
Signed-off-by: Robert Drazkowski <Robert.Drazkowski@globallogic.com>
Signed-off-by: Robert Drazkowski <Robert.Drazkowski@globallogic.com>
327c663
to
54f8aa1
Compare
@paulhowardarm |
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.
Thanks!! Looks good to me 👍
The only 'github' dependency is for "parsec-client' where github is updated but crates.io points on previous version. I hope this is not an issue.
To me it's fine as it's only used in the e2e_tests
crate!
Definition of new structures and their interfaces.
Known issues
Version mismatch of psa-crypto
There is a version mismatch in a dependent library (psa-crypto) between parsec-interface and parsec on appropriate master/HEAD versions:
The solution is to
As a workaround this PR modifies parsec/Cargo.toml to have the same psa-crypto as a parsec-interface.
Wrong parsec-interface version number being used
The parsec-interface extension (add an CryptoAuthLib entry to providers' enumeration) was not followed by package version increase nor the package meta-data on crates.io was updated. This PR addressed an issue with parsec-interface version for parsec compilation purposes but there are still issues with e2e-tests.
Issues with e2e-tests
The e2e-tests depend on parsec-client that depends on parsec-interface and it is affected by the previously mentioned versioning issues.
Summary TODO points
Signed-off-by: Robert Drazkowski Robert.Drazkowski@globallogic.com