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

crypto: Update to Mbed Crypto 1.0.0d1 #9463

Closed
wants to merge 6 commits into from

Conversation

Patater
Copy link
Contributor

@Patater Patater commented Jan 22, 2019

Description

Update Mbed Crypto to development version mbedcrypto-1.0.0d1 to facilitate rest-of-Mbed-OS integration with PSA Crypto API changes sooner.

In order to do this, we needed to break out the Mbed Crypto importing code from the Mbed TLS importer. This, in effect, adds a separate importer script for Mbed Crypto which can be used to directly import Mbed Crypto into Mbed OS.

Pull request type

[ ] Fix
[x] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

CC @avolinski @alzix @sbutcher-arm

@ciarmcom
Copy link
Member

@Patater, thank you for your changes.
@avolinski @sbutcher-arm @alzix @ARMmbed/mbed-os-crypto @ARMmbed/mbed-os-tls @ARMmbed/mbed-os-maintainers please review.

@Patater Patater force-pushed the update-mbedcrypto-1.0.0d0 branch from ad1a56f to adc242e Compare January 23, 2019 11:58
@Patater
Copy link
Contributor Author

Patater commented Jan 23, 2019

Rebased to correct explanation of NSPE and SPE.

Obtain the version of Mbed Crypto to use not from the Mbed TLS
submodule, but independently through the Mbed Crypto importer instead.
Use the Mbed-Crypto-specific importer script to re-import Mbed Crypto
0.1.0b2 to its new location.
Instead of doing a "pull --rebase" to update to the latest development
branch, do a "fetch" followed by a "checkout" to update to the specified
release. This enables us to get any new tags created since the last
update to the development branch, and removes the noise of updating a
local "development" branch.
@Patater Patater force-pushed the update-mbedcrypto-1.0.0d0 branch from adc242e to e71374f Compare January 23, 2019 11:59
@Patater
Copy link
Contributor Author

Patater commented Jan 23, 2019

Rebased to remove stray period.

Copy link
Contributor

@yanesca yanesca left a comment

Choose a reason for hiding this comment

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

Looks good to me.

Patater and others added 3 commits January 25, 2019 15:37
Update tests in TESTS/mbed-crypto/sanity/main.cpp
Test key handles by adding a test to TESTS/mbed-crypto/sanity/main.cpp
@Patater Patater force-pushed the update-mbedcrypto-1.0.0d0 branch from e71374f to bd0037f Compare January 25, 2019 15:39
@Patater Patater changed the title Update mbedcrypto 1.0.0d0 Update mbedcrypto 1.0.0d1 Jan 25, 2019
@Patater
Copy link
Contributor Author

Patater commented Jan 25, 2019

Rebased to update to Mbed Crypto 1.0.0d1. Added new commits from @itayzafrir to update the Mbed OS crypto tests.

@simonbutcher
Copy link
Contributor

@mpg - Could you please review this PR and check it's consistent with your architecture proposal?

@0xc0170 0xc0170 requested a review from mpg January 28, 2019 08:48
@mpg
Copy link

mpg commented Jan 28, 2019

@Patater I'm not that familiar with the importer, so I think it would help my review if you could describe at a high level what this does. Since you selected "refactor" as a PR type, I'm assuming the goal of this PR is to ensure that Mbed Crypto can be fetched from a different source (ie directly from the mbed-crypto repo rather than indirectly via the mbedtls repo and its submodule), but still be placed the same way in the Mbed OS source tree (ie still as a subdirectory of the mbedtls feature) and still built the same way (ie using config.h from the Mbed TLS tree and so on).

Can you confirm if that is the case, or clarify if I made wrong assumptions?

On an unrelated front, I'm getting the impression that updating to mbedcrypto 1.0.0d1 will break Mbed TLS, due to API changes that we haven't adapted to yet (and even if we had, we'd still need to import the relevant development version of Mbed TLS in Mbed OS for it to work). It looks like the CI isn't finding that issue so far, so perhaps it should be expanded as well?

@NirSonnenschein
Copy link
Contributor

because of interdependency issues with PR#9192 (#9192) they will need to go through CI together (each will fail on it's own, but both should pass together). If they can be unified into a single PR this might make this easier.

@Patater
Copy link
Contributor Author

Patater commented Jan 28, 2019

@mpg

Can you confirm if that is the case, or clarify if I made wrong assumptions?

Yes, that's the case. At a high level, this PR essentially reverts the Mbed TLS importer to how it was before Mbed OS 5.11. It takes the changes we added to the Mbed TLS importer in Mbed OS 5.11 to import Mbed Crypto and places those changes into their own Makefile which solely imports Mbed Crypto. This enables us to do development releases of Mbed Crypto into Mbed OS to help give others time to integrate with it well ahead of the next major Mbed OS release.

I'm getting the impression that updating to mbedcrypto 1.0.0d1 will break Mbed TLS, due to API changes that we haven't adapted to yet.

Yes, that's also the case for when the disabled-by-default option MBEDTLS_USE_PSA_CRYPTO is set. After the API is stable, we will avoid breaking this configuration by further imports into Mbed OS. Any API breakage will become obvious when Mbed OS CI tests with the MBEDTLS_USE_PSA_CRYPTO option set begin failing.

@Patater
Copy link
Contributor Author

Patater commented Jan 28, 2019

@NirSonnenschein This PR doesn't depend on #9192 as it doesn't bring in ITS changes yet. I'll raise a new PR for both the ITS changes from #9192 as well as ARMmbed/mbed-crypto#23, so that the review and merge process is simpler for this PR.

@NirSonnenschein
Copy link
Contributor

@Patater as long as there is no interdependency then this sounds like a good way forward.

@Patater Patater changed the title Update mbedcrypto 1.0.0d1 crypto: Update to Mbed Crypto 1.0.0d1 Jan 28, 2019
@NirSonnenschein
Copy link
Contributor

NirSonnenschein commented Jan 29, 2019

@Patater : I'm not sure if this requires final approval from the TLS team, but started CI in the mean time.

@mikisch81
Copy link
Contributor

@Patater looks like the PSA targets fail in compilation

@mbed-ci
Copy link

mbed-ci commented Jan 29, 2019

Test run: FAILED

Summary: 4 of 8 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

  • jenkins-ci/mbed-os-ci_build-ARMC6
  • jenkins-ci/mbed-os-ci_build-ARM
  • jenkins-ci/mbed-os-ci_build-GCC_ARM
  • jenkins-ci/mbed-os-ci_build-IAR

@NirSonnenschein
Copy link
Contributor

NirSonnenschein commented Jan 29, 2019

Hi @Patater : FYI , CI ran into 2 failures at the build stage:

  1. on sequana board compilation there were multiple build errors:
    10:14:47 [FUTURE_SEQUANA_PSA:ARM] [DEBUG] Output: "./components/TARGET_PSA/services/crypto/COMPONENT_PSA_SRV_IPC/crypto_platform_spe.h", line 105: Error: CAN-Related Pull Request #20: identifier "psa_key_slot_t" is undefined

  2. on K64F there was also an error:
    10:18:58 [K64F:ARM] ################################################################################
    10:18:58 [K64F:ARM] # Failed example combinations
    10:18:58 [K64F:ARM] ################################################################################
    10:18:58 [K64F:ARM] # mbed-os-example-mbed-crypto K64F ARM
    10:18:58 [K64F:ARM] #
    10:18:58 [K64F:ARM] ################################################################################
    10:18:58 [K64F:ARM] Number of failures = 1

@itayzafrir
Copy link
Contributor

@Patater compilation failed for target FUTURE_SEQUANA_PSA, this PR need additional commits from my PR #9409. We can cherry-pick all the commits from #9409 (except for 563701d which is the same as bd0037f from this PR) or only cherry-pick 3c10e5d.
If only cherry-pick 3c10e5d then function psa_hash_clone will return PSA_ERROR_NOT_SUPPORTED when doing crypto IPC.

@mikisch81
Copy link
Contributor

@Patater compilation failed for target FUTURE_SEQUANA_PSA, this PR need additional commits from my PR #9409. We can cherry-pick all the commits from #9409 (except for 563701d which is the same as bd0037f from this PR) or only cherry-pick 3c10e5d.
If only cherry-pick 3c10e5d then function psa_hash_clone will return PSA_ERROR_NOT_SUPPORTED when doing crypto IPC.

#9529 should have all the dependent PRs inside and tests should pass.

Individually it's not possible as all the PRs are mutually dependent.

@Patater
Copy link
Contributor Author

Patater commented Jan 29, 2019

Closing in favor of #9529

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

Successfully merging this pull request may close these issues.