Skip to content

Check coverage of TF-PSA-Crypto options in Mbed TLS #10536

@gilles-peskine-arm

Description

@gilles-peskine-arm

The combination of test_suite_config.mbedtls_boolean.data and test_suite_config.psa_boolean.data (generated by generate_config_tests.py) and analyze_outcomes.py gives us some assurance of test coverage: we know that every config option is tested in at least one build, and its absence is tested in at least one build. In other words, for every compile-time option MBEDTLS_FOO, outcome analysis will complain if all the builds we do in all.sh have MBEDTLS_FOO enabled, or if all the builds we do in all.sh have MBEDTLS_FOO disabled.

Since the repository split, this is done in TF-PSA-Crypto for its own options (there's no outcome analysis in crypto, but that's a separate issue), and it's done in Mbed TLS for its own options. However, we don't check that Mbed TLS has good coverage of crypto settings. For example, we don't check that Mbed TLS is tested both with RSA enabled and with RSA disabled.

Note that we don't want Mbed TLS to have full coverage of all TF-PSA-Crypto configuration options: only the ones that matter. For example, low-level optimization options don't matter since we're confident that the result is functionally identical, and options that affect features that Mbed TLS doesn't use don't matter.

Tentative definition, but I'm not sure that's right: ask crypto's config.py to list all the crypto options, and retain only the ones that appear in library. Those are the ones for which Mbed TLS must have test coverage. It's evidently not perfect (Mbed TLS could depend on a TF-PSA-Crypto option that changes the behavior, but only in a way that requires no compile-time choice for users), but maybe it's good enough? Of course we can have ad hoc additions and removals to that list, but they're likely to be hard to identify and maintain.

Goal of this issue: define and implement a list of relevant config options, and arrange to generate a test_suite_config.tf_psa_crypto_boolean.data accordingly. Document any identified caveats. If a lack of useful coverage is identified, file an issue and add an exception to analyze_outcomes.py.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    Status

    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions