-
Notifications
You must be signed in to change notification settings - Fork 38
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
base: development
Are you sure you want to change the base?
Move everest headers #235
Conversation
cbfabef
to
91fe5e9
Compare
36b5120
to
248d479
Compare
248d479
to
0cae869
Compare
3108d9d
to
a4ce107
Compare
Signed-off-by: Ben Taylor <[email protected]>
Signed-off-by: Ben Taylor <[email protected]>
Signed-off-by: Ben Taylor <[email protected]>
Signed-off-by: Ben Taylor <[email protected]>
Signed-off-by: Ben Taylor <[email protected]>
Signed-off-by: Ben Taylor <[email protected]>
Signed-off-by: Ben Taylor <[email protected]>
Signed-off-by: Ben Taylor <[email protected]>
d824ad0
to
1897fad
Compare
Signed-off-by: Ben Taylor <[email protected]>
1897fad
to
ca5bc62
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.
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 |
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 in mbedtls, no change to .gitmodules
is desirable or necessary.
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 change is temporary, it's just to test the dependent PR. It will be removed prior to the merge.
drivers/p256-m/CMakeLists.txt
Outdated
@@ -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/> |
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 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.
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, I'll give it a go removing it.
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.
Seems to work without it, so I removed it.
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.
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.
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 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.
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 additional info, I've reverted the removal now. I shall look into making the path private.
drivers/everest/CMakeLists.txt
Outdated
@@ -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/> |
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 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.
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.
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.
Signed-off-by: Ben Taylor <[email protected]>
Signed-off-by: Ben Taylor <[email protected]>
Signed-off-by: Ben Taylor <[email protected]>
Signed-off-by: Ben Taylor <[email protected]>
Signed-off-by: Ben Taylor <[email protected]>
Signed-off-by: Ben Taylor <[email protected]>
Signed-off-by: Ben Taylor <[email protected]>
Description
Move everest headers. Depends Mbed-TLS/mbedtls-framework#153
PR checklist