• Home
  • History
  • Annotate
Name Date Size #Lines LOC

..--

crypto/11-Mar-2024-28,73620,210

initial_attestation/11-Mar-2024-519359

storage/11-Mar-2024-5,8093,561

README.mdD11-Mar-202410.6 KiB13797

README.md

1
2# PSA Certified APIs Architecture Test Suite
3
4## PSA Certified APIs
5
6PSA 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 Certified APIs Specifications](https://arm-software.github.io/psa-api/).
7
8## Architecture test suite
9
10The architecture test suite is a set of examples of the invariant behaviors that are specified in the PSA Certified 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.
11
12This test suite is not a substitute for design verification. To review the test logs, Arm licensees can contact Arm directly through their partner managers.
13
14For more information on the architecture test suite framework and methodology to run the tests, refer to the [Validation Methodology](../docs/Arm_PSA_APIs_Arch_Test_Validation_Methodology.pdf) document.
15
16## This release
17 - Code Quality : REL v1.4
18 - This release contains following API tests: <br />
19
20| Test Category            | Specification Version                |
21|--------------------------|--------------------------------------|
22| Crypto                   | [Crypto API 1.0.1](https://arm-software.github.io/psa-api/crypto/)     |
23| Storage (PS and ITS)     | [Storage API 1.0.0](https://arm-software.github.io/psa-api/storage/) |
24| Attestation              | [Attestation API 1.0.2](https://arm-software.github.io/psa-api/attestation/)  |
25
26
27##  Release Tags
28
29 - For API certification, use release tag from below table:
30
31| Release version | Release tag  | Crypto API | Storage API | Attestation API |
32|-----------------|---------------|----------------|-----------------|---------------------|
33| REL v1.4 | [v22.01_API1.4_ADAC_BETA](https://github.com/ARM-software/psa-arch-tests/tree/v22.01_API1.4_ADAC_BETA/api-tests/dev_apis) | 1.0.1  | 1.0.0 | 1.0.2 |
34| REL v1.3 | [v21.10_API1.3_ADAC_ALPHA-1](https://github.com/ARM-software/psa-arch-tests/tree/v21.10_API1.3_ADAC_ALPHA-1/api-tests/dev_apis) | 1.0.0  | 1.0.0 | 1.0.2 |
35| REL v1.2 | [v21.07_API1.2_ADAC_ALPHA](https://github.com/ARM-software/psa-arch-tests/tree/v21.07_API1.2_ADAC_ALPHA/api-tests/dev_apis) | 1.0.0  | 1.0.0 | 1.0.2 |
36| REL v1.1 | [v20.11_API1.1](https://github.com/ARM-software/psa-arch-tests/tree/v20.11_API1.1/api-tests/dev_apis) | 1.0-Beta3  | 1.0.0 | 1.0.0 |
37| REL v1.0 | [v20.03_API1.0](https://github.com/ARM-software/psa-arch-tests/tree/v20.03_API1.0/api-tests/dev_apis) | 1.0-Beta3  | 1.0.0 | 1.0.0 |
38| v0.9 | [v19.06_API0.9](https://github.com/ARM-software/psa-arch-tests/tree/v19.06_API0.9/api-tests/dev_apis) | 1.0-Beta2 | 1.0-Beta2 | 1.0-Beta0 |
39| v0.8 | [v19.02_API0.8](https://github.com/ARM-software/psa-arch-tests/tree/v19.02_API0.8/api-tests/dev_apis) | 1.0-Beta1 | 1.0-Beta0 | 1.0-Beta0 |
40
41## Test scenarios
42
43The mapping of the rules in the specification to the test cases and the steps followed in the tests are mentioned in the [Scenario Document](../docs/) that is present in the **docs/** folder.
44
45
46## Getting started
47
48Follow 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](../docs/sw_requirements.md).
49
50### Porting steps
51
52Refer to the [PSA Certified APIs Test Suite Porting Guide](../docs/porting_guide_dev_apis.md) document for porting steps.
53
54### Build steps
55
56To build the test suite for your target platform, execute the following commands:
57
58```
59    cd api-tests
60    mkdir <build_dir>
61    cd <build_dir>
62    cmake ../ -G"<generator_name>" -DTARGET=<platform_name> -DCPU_ARCH=<cpu_architecture_version> -DSUITE=<suite_name> -DPSA_INCLUDE_PATHS="<include_path1>;<include_path2>;...;<include_pathn>"
63    cmake --build .
64```
65<br />Options information:<br />
66
67-   -G"<generator_name>" : "Unix Makefiles" to generate Makefiles for Linux and Cygwin. "MinGW Makefiles" to generate Makefiles for cmd.exe on Windows  <br />
68-   -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](../docs/test_failure_analysis.md) document to know the reason for any known test fail.<br />
69-   -DTOOLCHAIN=<tool_chain> Compiler toolchain to be used for test suite compilation. Supported values are GNUARM (GNU Arm Embedded), ARMCLANG (ARM Compiler 6.x) , HOST_GCC and GCC_LINUX . Default is GNUARM.<br />
70-   -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, armv7m and armv8a. Default is empty. This option is unused when TOOLCHAIN type is HOST_GCC.<br />
71-   -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 .<br />
72-   -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).
73-   -DBUILD=<BUILD_DIR> : To select the build directory to keep output files. Default is BUILD/ inside current directory.
74-   -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 API behaviour on the system reset.
75-   -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.
76-   -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.
77-   -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. <br/>
78     If -DSPEC_VERSION option is not given it will build for latest version of testsuite.
79     For every spec version corresponds test list will be in spec_version_testsuite.db file in api-tests/dev_apis/test_suite_name/ folder.
80-   -DCOMPILER_NAME=<compiler_name> Compiler name to be use for selecting compiler. Supported values are gcc. By defualt it will take gcc if not specified.
81     Note: -DCOMPILER_NAME only applicable for linux i.e. -DTOOLCHAIN=GCC_LINUX and DTARGET=tgt_dev_apis_linux.
82-   -DPSA_INCLUDE_PATHS="<include_path1>;<include_path2>;...;<include_pathn>" is an additional directory to be included into the compiler search path.You must provide API 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:<br />
83-   -DPSA_TARGET_QCBOR=<path for pre-fetched cbor folder, this is option used where no network connectivity is possible during the build:<br />
84```
85    -DPSA_INCLUDE_PATHS=`readlink -f <relative_include_path>`
86```
87-   -DTESTS_COVERAGE=<tests_coverage_value> is used to skip known failure tests by selecting value PASS. Supported values are ALL and PASS. ALL value will include all the tests and PASS value will skip the known failure tests and will include pass tests. Default is ALL.
88
89To compile Crypto tests for **tgt_dev_apis_tfm_an521** platform, execute the following commands:
90```
91    cd api-tests
92    mkdir BUILD
93    cd  BUILD
94    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>"
95    cmake --build .
96```
97
98### Build output
99Building the test suite generates the following NSPE binaries:<br />
100- **<build_dir>/val/val_nspe.a**
101- **<build_dir>/platform/pal_nspe.a**
102- **<build_dir>/dev_apis/<suite_name>/test_combine.a**
103
104### Integrating the libraries into your target platform
105
1061. 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 APIs. For example, Crypto tests require access to Crypto APIs. This forms an NSPE binary.
1072. Load the NSPE binary to the Non-secure memory.
1083. Build your SPE binary and load into the Secure memory.
109
110## Test suite execution
111The following steps describe the execution flow before the test execution: <br />
112
1131. The target platform must load the above binaries into appropriate memory. <br />
1143. 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. <br />
1154. The tests are executed sequentially in a loop in the test_dispatcher function. <br />
116
117For details on test suite integration, refer to the **Integrating the test suite with the SUT** section of [Validation Methodology](../docs/Arm_PSA_APIs_Arch_Test_Validation_Methodology.pdf).
118
119## Security implication
120
121The 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 the 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.
122
123## License
124
125Arm PSA test suite is distributed under Apache v2.0 License.
126
127## Feedback, contributions, and support
128
129 - For feedback, use the GitHub Issue Tracker that is associated with this repository.
130 - For support, send an email to support-psa-arch-tests@arm.com with details.
131 - Arm licensees can contact Arm directly through their partner managers.
132 - Arm welcomes code contributions through GitHub pull requests.
133
134--------------
135
136*Copyright (c) 2018-2022, Arm Limited and Contributors. All rights reserved.*
137