Skip to content

Make a proper Python internal API for test PSA dependency inference #7845

@gilles-peskine-arm

Description

@gilles-peskine-arm

We have some Python code to automatically determine the dependencies of a test case using the PSA crypto API based on the mechanisms that it uses.

The basic idea is that any code that uses a PSA_xxx value has a dependency on PSA_WANT_xxx, but there are additional compliations: PSA_ECC_CURVE_xxx and PSA_DH_GROUP_xxx also encode the size in the PSA_WANT symbol; PSA_KEY_TYPE_xxx_KEY_PAIR also encode the operation in the PSA_WANT symbol.

The code to deal with these complications, as of 717a831 (mbedtls 3.4+), is mostly in generate_psa_tests.py, partly at the top and partly special cases in various functions (in particular, related to key pair usage, following the work around #7439). There's also some independent code in the bitrotting set_psa_test_dependencies.py (which we used to translate MBEDTLS_xxx dependencies to PSA dependencies a while ago, but don't use regularly now).

#7803 starts to move this code into a new Python module psa_information.py so that it can be used in code that's independent from the code in generate_psa_tests.py that's about enumerating all crypto mechanisms.

The goal of this task is to factor the recode in generate_psa_tests.py (or, by the time we address this issue, code that was originally in generate_psa_tests.py) so that callers can generally call one function/method infer_psa_dependencies which goes and analyzes the mechanisms that the test case uses and generates the PSA_WANT dependency list. That function would probably need an extra argument indicating what's done with the key involved (at least for the common case of having ≤1 key) to distinguish between the KEY_PAIR usage variants. Designing the exact interface (function names, argument lists, etc.) is part of this task. We just needs an interface that works now, not one that's fully future-proof, since the interface can evolve as needed.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions