PSA defines security service APIs for application developers. Some of these services are Crypto, Attestation, and Secure storage. For more information on API specifications, refer to the PSA Functional APIs Specifications.
The architecture test suite is a set of examples of the invariant behaviors that are specified in the PSA Functional APIs specifications. Use this suite to verify whether these behaviors are implemented correctly in your system. This suite contains self-checking and portable C-based tests with directed stimulus. These tests are available as open source. The tests and the corresponding abstraction layers are available with an Apache v2.0 license, allowing external contribution.
This test suite is not a substitute for design verification. To review the test logs, Arm licensees can contact Arm directly through their partner managers.
For more information on the architecture test suite framework and methodology to run the tests, refer to the Validation Methodology document.
- Code Quality : REL v1.1
- This release contains following PSA Functional APIs tests:
| Test Category | Specification Version |
|---|---|
| Crypto | PSA Crypto API 1.0-Beta3 |
| Storage (PS and ITS) | PSA Storage API 1.0.0 |
| Attestation | PSA Attestation API 1.0.0 |
- For PSA Functional API certification, use release tag from below table:
| Release version | Release tag | PSA Crypto API | PSA Storage API | PSA Attestation API |
|---|---|---|---|---|
| REL v1.1 | v20.11_API1.1 | 1.0-Beta3 | 1.0.0 | 1.0.0 |
| REL v1.0 | v20.03_API1.0 | 1.0-Beta3 | 1.0.0 | 1.0.0 |
| v0.9 | v19.06_API0.9 | 1.0-Beta2 | 1.0-Beta2 | 1.0-Beta0 |
| v0.8 | v19.02_API0.8 | 1.0-Beta1 | 1.0-Beta0 | 1.0-Beta0 |
The mapping of the rules in the specification to the test cases and the steps followed in the tests are mentioned in the Scenario Document that is present in the docs/ folder.
Follow the instructions in the subsequent sections to get a copy of the source code on your local machine and build the tests. Make sure you have all required software installed as explained in the Software Requirements Document.
Refer to the PSA Functional APIs Test Suite Porting Guide document for porting steps.
To build the test suite for your target platform, execute the following commands:
cd api-tests
mkdir <build_dir>
cd <build_dir>
cmake ../ -G"<generator_name>" -DTARGET=<platform_name> -DCPU_ARCH=<cpu_architecture_version> -DSUITE=<suite_name> -DPSA_INCLUDE_PATHS="<include_path1>;<include_path2>;...;<include_pathn>"
cmake --build .
Options information:
- -G"<generator_name>" : "Unix Makefiles" to generate Makefiles for Linux and Cygwin. "MinGW Makefiles" to generate Makefiles for cmd.exe on Windows
- -DTARGET=<platform_name> is the same as the name of the target-specific directory created in the platform/targets/ directory. The current release has been tested on tgt_dev_apis_tfm_an521, tgt_dev_apis_tfm_musca_b1 and tgt_dev_apis_tfm_musca_a platforms. Refer Test_failure analysis document to know the reason for any known test fail.
- -DTOOLCHAIN=<tool_chain> Compiler toolchain to be used for test suite compilation. Supported values are GNUARM (GNU Arm Embedded), ARMCLANG (ARM Compiler 6.x) and HOST_GCC. Default is GNUARM.
- -DCPU_ARCH=<cpu_architecture_version> is the Arm Architecture version name for which the tests should be compiled. Supported CPU arch are armv8m_ml, armv8m_bl and armv7m. Default is empty. This option is unused when TOOLCHAIN type is HOST_GCC.
- -DSUITE=<suite_name> is the test suite name. Supported values are CRYPTO, INITIAL_ATTESTATION, STORAGE(INTERNAL_TRUSTED_STORAGE and PROTECTED_STORAGE), INTERNAL_TRUSTED_STORAGE and PROTECTED_STORAGE .
- -DVERBOSE=<verbose_level>. Print verbosity level. Default is 3. Supported print levels are 1(INFO & above), 2(DEBUG & above), 3(TEST & above), 4(WARN & ERROR) and 5(ERROR).
- -DBUILD=<BUILD_DIR> : To select the build directory to keep output files. Default is BUILD/ inside current directory.
- -DWATCHDOG_AVAILABLE=<0|1>: Test harness may require to access watchdog timer to recover system hang. 0 means skip watchdog programming in the test suite and 1 means program the watchdog. Default is 1. Note, watchdog must be available for the tests which check the PSA API behaviour on the system reset.
- -DSUITE_TEST_RANGE="<test_start_number>;<test_end_number>" is to select range of tests for build. All tests under -DSUITE are considered by default if not specified.
- -DTFM_PROFILE=<profile_small/profile_medium> is to work with TFM defined Pofile Small/Medium definitions. Supported values are profile_small and profile_medium. Unless specified Default Profile is used.
- -DSPEC_VERSION=<spec_version> is test suite specification version. Which will build for given specified spec_version. Supported values for CRYPTO test suite are 1.0-BETA1, 1.0-BETA2, 1.0-BETA3 , for INITIAL_ATTESATATION test suite are 1.0-BETA0, 1.0.0, 1.0.1, 1.0.2, for STORAGE, INTERNAL_TRUSTED_STORAGE, PROTECTED_STORAGE test suite are 1.0-BETA2, 1.0 . Default is empty.
If -DSPEC_VERSION option is not given it will build for latest version of testsuite. For every spec version corresponds test list will be in spec_version_testsuite.db file in api-tests/dev_apis/test_suite_name/ folder. - -DPSA_INCLUDE_PATHS="<include_path1>;<include_path2>;...;<include_pathn>" is an additional directory to be included into the compiler search path.You must provide Functional APIs header files implementation to the test suite build system using this option. For example, to compile Crypto tests, the include path must point to the path where psa/crypto.h is located in your build system. Bydefault, PSA_INCLUDE_PATHS accepts absolute path. However, relative path can be provided using below format:
-DPSA_INCLUDE_PATHS=`readlink -f <relative_include_path>`
To compile Crypto tests for tgt_dev_apis_tfm_an521 platform, execute the following commands:
cd api-tests
mkdir BUILD
cd BUILD
cmake ../ -G"Unix Makefiles" -DTARGET=tgt_dev_apis_tfm_an521 -DCPU_ARCH=armv8m_ml -DSUITE=CRYPTO -DPSA_INCLUDE_PATHS="<include_path1>;<include_path2>;...;<include_pathn>"
cmake --build .
Building the test suite generates the following NSPE binaries:
- <build_dir>/val/val_nspe.a
- <build_dir>/platform/pal_nspe.a
- <build_dir>/dev_apis/<suite_name>/test_combine.a
- Integrate val_nspe.a, pal_nspe.a, and test_combine.a libraries with your Non-secure OS so that these libraries get access to the PSA Functional APIs. For example, Crypto tests require access to PSA Crypto APIs. This forms an NSPE binary.
- Load the NSPE binary to the Non-secure memory.
- Build your SPE binary and load into the Secure memory.
The following steps describe the execution flow before the test execution:
- The target platform must load the above binaries into appropriate memory.
- Upon booting firmware and Non-secure OS, the SUT boot software gives control to the test suite entry point int32_t val_entry(void); as an Non-secure application entry point returning test status code.
- The tests are executed sequentially in a loop in the test_dispatcher function.
For details on test suite integration, refer to the Integrating the test suite with the SUT section of Validation Methodology.
PSA API test suite may run at higher privilege level. An attacker can utilize these tests as a means to elevate privilege which can potentially reveal the platform secure attests. To prevent such security vulnerabilities into the production system, it is strongly recommended that PSA API test suite is run on development platforms. If it is run on production system, make sure system is scrubbed after running the test suite.
Arm PSA test suite is distributed under Apache v2.0 License.
- For feedback, use the GitHub Issue Tracker that is associated with this repository.
- For support, send an email to [email protected] with details.
- Arm licensees can contact Arm directly through their partner managers.
- Arm welcomes code contributions through GitHub pull requests.
Copyright (c) 2018-2021, Arm Limited and Contributors. All rights reserved.