Skip to content

Move everest headers #235

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

Open
wants to merge 16 commits into
base: development
Choose a base branch
from

Conversation

bjwtaylor
Copy link

@bjwtaylor bjwtaylor commented Mar 24, 2025

Description

Move everest headers. Depends Mbed-TLS/mbedtls-framework#153

PR checklist

  • changelog provided
  • framework PR not required
  • mbedtls development PR provided Move everest headers mbedtls#10091
  • mbedtls 3.6 PR not required because: No Backports
  • mbedtls 2.28 PR not required because: No Backports
  • tests not required because: No changes

@bjwtaylor bjwtaylor force-pushed the move-everest-headers branch 8 times, most recently from cbfabef to 91fe5e9 Compare March 31, 2025 07:55
@bjwtaylor bjwtaylor force-pushed the move-everest-headers branch 2 times, most recently from 36b5120 to 248d479 Compare April 2, 2025 08:42
@bjwtaylor bjwtaylor force-pushed the move-everest-headers branch from 248d479 to 0cae869 Compare April 3, 2025 09:52
@bjwtaylor bjwtaylor marked this pull request as ready for review April 4, 2025 06:43
@bjwtaylor bjwtaylor added needs-review Every commit must be reviewed by at least two team members needs-reviewer This PR needs someone to pick it up for review labels Apr 8, 2025
@felixc-arm felixc-arm self-requested a review April 15, 2025 10:01
@bjwtaylor bjwtaylor force-pushed the move-everest-headers branch 5 times, most recently from 3108d9d to a4ce107 Compare April 22, 2025 08:34
@bjwtaylor bjwtaylor force-pushed the move-everest-headers branch 4 times, most recently from d824ad0 to 1897fad Compare April 23, 2025 06:56
Signed-off-by: Ben Taylor <[email protected]>
@bjwtaylor bjwtaylor force-pushed the move-everest-headers branch from 1897fad to ca5bc62 Compare April 23, 2025 11:53
@gilles-peskine-arm gilles-peskine-arm self-requested a review April 24, 2025 09:32
@gilles-peskine-arm gilles-peskine-arm added priority-high High priority - will be reviewed soon and removed needs-reviewer This PR needs someone to pick it up for review labels Apr 24, 2025
Copy link
Contributor

@gilles-peskine-arm gilles-peskine-arm 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 apart from .gitmodules, and apart from some issues which are at least partly preexisting and I'm not sure whether they're in scope right now or need to be part of some larger fix.

@@ -1,3 +1,3 @@
[submodule "framework"]
path = framework
url = https://github.com/Mbed-TLS/mbedtls-framework
url = git@github.com:bjwtaylor/mbedtls-framework.git
Copy link
Contributor

Choose a reason for hiding this comment

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

As in mbedtls, no change to .gitmodules is desirable or necessary.

Copy link
Author

Choose a reason for hiding this comment

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

This change is temporary, it's just to test the dependent PR. It will be removed prior to the merge.

@@ -11,7 +11,7 @@ target_include_directories(${p256m_target}
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/p256-m>
$<BUILD_INTERFACE:${TF_PSA_CRYPTO_DIR}/include>
$<BUILD_INTERFACE:${TF_PSA_CRYPTO_DIR}/drivers/builtin/include>
$<BUILD_INTERFACE:${TF_PSA_CRYPTO_DIR}/drivers/everest/include>
$<BUILD_INTERFACE:${TF_PSA_CRYPTO_DIR}/drivers/everest/include/tf-psa-crypto/private/>
Copy link
Contributor

Choose a reason for hiding this comment

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

I suppose that's out of scope, but I find this line weird: why would users of p256-m be built with any knowledge of Everest? This looks like a global change that shouldn't have been applied to this file. Can you please try just removing this line?

Everest headers do need to be available privately when building p256-m, however. There's no functional dependency, but p256-m.c calls psa_generate_random, which is declared in psa/crypto.h, which indirectly includes the header where Everest defines its ECDH context type. So maybe the line needs to be moved to the PRIVATE section and not removed.

Copy link
Author

Choose a reason for hiding this comment

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

Ok, I'll give it a go removing it.

Copy link
Author

Choose a reason for hiding this comment

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

Seems to work without it, so I removed it.

Copy link
Author

Choose a reason for hiding this comment

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

Interesting, this change seems to cause a failure when MBEDTLS_ECDH_VARIANT_EVEREST_ENABLED is defined. Not sure if it's related to the next issue, I shall investigate.

Copy link
Contributor

@ronald-cron-arm ronald-cron-arm Apr 25, 2025

Choose a reason for hiding this comment

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

This caught my eyes as it is indeed strange to have an everest include path for p256-m. Looking at it, it seems it is because p256-m code include psa/crypto.h which when MBEDTLS_ECDH_VARIANT_EVEREST_ENABLED is enabled includes eventually everest/everest.h. It is probably somehow wrong for a driver to include psa/crypto.h but that's not an easy thing to change I'd say. The everest include path should be private though.

Copy link
Author

Choose a reason for hiding this comment

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

Thanks for the additional info, I've reverted the removal now. I shall look into making the path private.

@@ -11,8 +11,9 @@ target_include_directories(${everest_target}
$<BUILD_INTERFACE:${TF_PSA_CRYPTO_DIR}/include>
$<BUILD_INTERFACE:${TF_PSA_CRYPTO_DIR}/drivers/builtin/include>
$<INSTALL_INTERFACE:include>
PRIVATE include/everest
include/everest/kremlib
PRIVATE $<BUILD_INTERFACE:${TF_PSA_CRYPTO_DIR}/drivers/everest/include/tf-psa-crypto/private/>
Copy link
Contributor

Choose a reason for hiding this comment

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

This may be preexisting, but the declaration of include paths is wrong here: at least some of these directories need to be public. Note that there's a clash in terminology:

  • In the 1.0/4.0 work, I've called APIs “public” if they're documented and meant to be used in application code, and “private” otherwise. Everest is private since it's an implementation detail. However, it needs to be “exposed” because there's an opaque struct that has a field whose type is defined by an Everest header.
  • In CMake, a “private” header is one that is only needed when compiling the project, while a “public” header is one that consuming projects need to have access to. At least part of Everest is public in this sense — that's what “exposed” means for a header.

To test that, run cmake --install . --prefix /tmp/235 after building with MBEDTLS_ECDH_VARIANT_EVEREST_ENABLED and try compiling a source file containing just #include <psa/crypto.h> with cc -I /tmp/235/include. This fails because #include "everest/everest.h" cannot be fulfilled. You can also see that it's missing from the log of cmake --install.

Using Mbed TLS from another project is currently broken in other ways and untested, so this may be an issue that we file for later. These issues are critical for the 1.0/4.0 release.

Copy link
Author

Choose a reason for hiding this comment

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

So, there was another issue with the install path which I have now corrected. I have also moved the header to public as requested. Let me know what you think and lets see if the CI highlights anything though.

@gilles-peskine-arm gilles-peskine-arm added needs-work and removed needs-review Every commit must be reviewed by at least two team members labels Apr 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-work priority-high High priority - will be reviewed soon
Projects
Development

Successfully merging this pull request may close these issues.

4 participants