sys/psa_crypto: Fix build problems#19992
Conversation
8ef66db to
9473ef2
Compare
e669c7d to
52a7186
Compare
MrKevinWeiss
left a comment
There was a problem hiding this comment.
Though I am not really in the PSA field I think it looks OK, and this does fix known issues. only nitpick comments there... Maybe it would be good to post the configurations that were tested. If anyone else wants to go more in-depth that would be appreciated but it would be nice to get this backported for the release. ping @Teufelchen1 maybe?
pkg/cryptoauthlib/Makefile.include
Outdated
| @@ -29,5 +29,7 @@ endif | |||
|
|
|||
| ifneq (,$(filter psa_crypto,$(USEMODULE))) | |||
There was a problem hiding this comment.
I actually don't think we need the ifneq for PSEUDOMODULES, this can be done in another PR but also... there is a lot of cleanup happening anyway.
| /** | ||
| * @brief Structure containing a hash context and algorithm | ||
| */ | ||
| struct psa_hash_operation_s { | ||
| psa_algorithm_t alg; /**< Operation algorithm */ | ||
| #if IS_USED(MODULE_PSA_HASH) | ||
| psa_hash_context_t ctx; /**< Operation hash context */ | ||
| #endif | ||
| }; | ||
|
|
||
| /** | ||
| * @brief This macro returns a suitable initializer for a hash operation object of type | ||
| * @ref psa_hash_operation_t. | ||
| */ | ||
| #define PSA_HASH_OPERATION_INIT { 0 } | ||
|
|
||
| /** | ||
| * @brief Return an initial value for a hash operation object. | ||
| * | ||
| * @return struct psa_hash_operation_s | ||
| */ | ||
| static inline struct psa_hash_operation_s psa_hash_operation_init(void) | ||
| { | ||
| const struct psa_hash_operation_s v = PSA_HASH_OPERATION_INIT; | ||
|
|
||
| return v; | ||
| } | ||
|
|
There was a problem hiding this comment.
Did you need to move this chunk below? Less changes that better (at least from the review perspective).
There was a problem hiding this comment.
I wanted to sort them by alphabet, but of course I can change this back
There was a problem hiding this comment.
I think it makes sense to maintain the new order to only have one continuous block of hash-related things to be guarded by the if-directive.
|
I get a lot of compile errors with the following configuration (copied from the initial post without the secure element): USEMODULE += psa_crypto
USEMODULE += psa_hash
USEMODULE += psa_hash_sha_256
Maybe the functions in |
mguetschow
left a comment
There was a problem hiding this comment.
Here a somewhat more in-depth review. As discussed (off-thread) before, I am in favor of the suggested changes which compile more code only on-demand, hidden behind a small set of PSA_<FEATURE> module flags, which are quite easy to reason about.
The example of the failed compilation above is just another pointer to the fact that we definitely need some sort of configuration tests in a future PR.
| USEMODULE += psa_key_slot_mgmt | ||
| USEMODULE += psa_key_management |
There was a problem hiding this comment.
Why do we have both psa_key_slot_mgmt and psa_key_management now? Seems to me like the latter is only sort of an alias for the former?
There was a problem hiding this comment.
It's not really the same. I separate between the PSA key management functions which are described by the specification and are exposed to the user in psa_crypto.c and psa/crypto.h vs. the key slot management module, which contains the whole key slot logic and is its own backend module.
They are dependent on each other, so if you build the key management functions, the key slot management is built, but they are separate things.
| * your sourcefiles, the module name will be the same as the directory name. It is possible | ||
| * to change that by declaring a new module name in the Makefile by adding the line | ||
| * your_module_name`. | ||
| * `MODULE := your_module_name`. |
There was a problem hiding this comment.
Kind of unrelated here, but while reading this I was wondering if there is more information about how paths are matched to module names in RIOT. Is it path/to/module => path_to_module in general? Maybe linking to further documentation, if existing, or giving an example might be worth it.
There was a problem hiding this comment.
It is indirectly mentioned here, but I haven't found a more detailed explanation, yet. I kind of figured this out on my own by using modules and submodules.
There was a problem hiding this comment.
according to @miri64 and how I understand the wiki, it's actually path/to/module => module (just for future reference)
sys/psa_crypto/doc.txt
Outdated
| * @endcode | ||
| * This needs to be done for all other supported operations (e.g. ATECCX08 operations in | ||
| * `pkg/cryptoauthlib/Makefile.include`, `pkg/cryptoauthlib/Makefile.dep` and | ||
| * `sys/psa_crypto/psa_se_mgmt/Kconfig` Now the secure element should be available for use |
There was a problem hiding this comment.
| * `sys/psa_crypto/psa_se_mgmt/Kconfig` Now the secure element should be available for use | |
| * `sys/psa_crypto/psa_se_mgmt/Kconfig`. Now the secure element should be available for use |
sys/psa_crypto/Kconfig.keys
Outdated
| config PSA_SINGLE_KEY_COUNT | ||
| int "Specifies number of allocated single key slots" | ||
| default 5 if PSA_MAX_KEY_SIZE != 0 | ||
| default 5 if MODULE_PSA_KEY_SLOT_MGMT |
There was a problem hiding this comment.
in crypto_sizes.h, you've changed the default to 0 (same as for PSA_ASYMMETRIC_KEYPAIR_COUNT).
| unlock_status = psa_unlock_key_slot(slot); | ||
| return ((status == PSA_SUCCESS) ? unlock_status : status); | ||
| } | ||
| #endif /* MODULE_PSA_ASYMMETRIC */ |
There was a problem hiding this comment.
Maybe not something for this PR, but since the CI is complaining about the long file: Should we maybe split the implementation files psa_crypto.c and also psa_crypto_{algorithm,location}_dispatch.c into smaller files, each only covering the implementation of one psa module such as MODULE_PSA_ASYMMETRIC? Since we have them already separated in blocks with the #if directives.
There was a problem hiding this comment.
I have thought about it at one point and I am totally not opposed to it. But you're right, it's a thing for the future.
|
|
||
| config MODULE_PSA_KEY_SLOT_MGMT | ||
| bool | ||
| default y if MODULE_PSA_KEY_MANAGEMENT |
There was a problem hiding this comment.
Shouldn't maybe MODULE_PSA_KEY_MANAGEMENT depend on MODULE_PSA_KEY_SLOT_MGMT instead? (If we want to keep the two aliases (?))
| config MODULE_PSA_KEY_SLOT_MGMT | ||
| bool | ||
| default y if MODULE_PSA_KEY_MANAGEMENT | ||
| default y if PACKAGE_PSA_ARCH_TESTS |
There was a problem hiding this comment.
Does this package actually exist?
d504a55 to
fe25fe1
Compare
|
@MrKevinWeiss I don't really understand that error thrown by Murdock. Is this something I need to take care of? For context: I made another rebase, could that be the problem? |
|
It is a unrelated issue I think. Murdock has been acting strange. |
|
Looks like you need to add new boards (at least the |
|
You can also run |
fe25fe1 to
217707b
Compare
217707b to
03f2bb9
Compare
03f2bb9 to
a4845bd
Compare
|
whyyyyyyy! |
|
Finally! Well done @Einhornhool |
Sorry that was me and the SHA512 support I guess :P congrats everyone that we have it in now! |
Contribution description
This fixes several problems:
1. Empty union in cipher context when
MODULE_PSA_CIPHERis not selected.PSA operations are now separated into modules. Functions and contexts are only built when the corresponding module is selected. This way there won't be problems with missing or unitialized structures in unused modules anymore.
2. Zero-size array when using secure elements and
PSA_MAX_KEY_DATA_SIZE == 0I added a condition to the
psa_key_slot_tstructure inpsa_key_slot_management.h.Also the existence of key slot management functions and key slot structures now depends on the number of allocated key slots instead of selected modules.
This way key structures will not exist unless they are used.
Testing procedure
Add the following to
examples/hello_world/Makefileand call make :Output on Master:
Output with fixes: