1 2# PSA Firmware Framework Architecture Test Suite 3 4## PSA Firmware Framework 5 6*PSA Firmware Framework* (PSA-FF) defines a standard interface and framework to isolate trusted functionality within constrained IoT devices. 7 8The framework provides: 9- Architecture that describes isolated runtime environments (partitions) for trusted and untrusted firmware. 10- A standard model for describing the functionality and resources in each partition. 11- A Secure IPC interface to request services from other partitions. 12- A model that describes how the partitions can interact with one another, as well as the hardware and the firmware framework implementation itself. 13- A standard interface for the PSA RoT services such as PSA RoT lifecycle service. 14 15This specification enables the development of Secure firmware functionality which can be reused on different devices that use any conforming implementation of the Firmware Framework. For more information, download the [PSA-FF Specification](https://pages.arm.com/psa-resources-ff.html?_ga=2.97388575.1220230133.1540547473-1540784585.1540547382). 16 17### Architecture test suite 18 19The architecture test suite is a set of examples of the invariant behaviors that are specified by the PSA-FF specification. 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. The tests are available as open source. The tests and the corresponding abstraction layers are available with an Apache v2.0 license allowing for external contribution. 20 21This test suite is not a substitute for design verification. To review the test logs, Arm licensees can contact Arm directly through their partner managers. 22 23For more information on architecture test suite specification, refer to the [Validation Methodology](../docs/Arm_PSA_APIs_Arch_Test_Validation_Methodology.pdf) document. 24 25## This release 26 - Code Quality : REL v1.4 27 - This release contains the PSA-FF tests that are written for the PSA FF 1.1 Extensions specification. 28 29## Release Tags 30 31| Release version | Release tag | PSA FF specification version | 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/ff) | 1.1-Alpha0 | 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/ff) | 1.1-Alpha0 | 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/ff) | 1.1-Alpha0 | 36| REL v1.1 | [v20.11_API1.1](https://github.com/ARM-software/psa-arch-tests/tree/v20.11_API1.1/api-tests/ff) | 1.0 | 37| REL v1.0 | [v20.03_API1.0](https://github.com/ARM-software/psa-arch-tests/tree/v20.03_API1.0/api-tests/ff) | 1.0 | 38| v0.9 | [v19.06_API0.9](https://github.com/ARM-software/psa-arch-tests/tree/v19.06_API0.9/api-tests/ff) | 1.0-Beta1 | 39| v0.8 | [v19.02_API0.8](https://github.com/ARM-software/psa-arch-tests/tree/v19.02_API0.8/api-tests/ff) | 1.0-Beta0 | 40 41## Tests 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/) 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](../docs/sw_requirements.md). 49 50### Porting steps 51 52Refer to the [PSA-FF Test Suite Porting Guide](../docs/porting_guide_ff.md) document for porting steps. 53 54### Build steps 55 56To build the test suite for your target platform, perform the following steps. 57 581. Execute `cd api-tests`. 59 602. Execute `python tools/scripts/manifest_update.py` to remove heap_size field from PSA test suite manifest files if your platform doesn't support the dynamic memory functions for the secure partition. Otherwise, skip this step. 61 623. Using your Secure partition build tool, parse the following test suite partition manifest files and generate manifest output files. The manifest parsing tool must be compliant with the manifest rules defined in the PSA FF specification.<br /> 63 <br />The test suite manifests to be parsed are:<br /> 64 - **platform/manifests/driver_partition_psa.json** 65 - **platform/manifests/client_partition_psa.json** 66 - **platform/manifests/server_partition_psa.json** 67 684. Compile the tests as shown below. <br /> 69``` 70 cd api-tests 71 mkdir <build_dir> 72 cd <build_dir> 73 cmake ../ -G"<generator_name>" -DTARGET=<platform_name> -DCPU_ARCH=<cpu_architecture_version> -DSUITE=<suite_name> -DPSA_INCLUDE_PATHS="<include_path1>;<include_path2>;...;<include_pathn>" 74 cmake --build . 75``` 76<br />Options information:<br /> 77 78- -G"<generator_name>" : "Unix Makefiles" to generate Makefiles for Linux and Cygwin. "MinGW Makefiles" to generate Makefiles for cmd.exe on Windows <br /> 79- -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 except for the tests written for PSA isolation level-3 and secure partition dynamic memory APIs as these features are unsupported by the mentioned platforms. However, it can still be possible to run them if the platform supports these features.<br /> 80- -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.<br /> 81- -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.<br /> 82- -DSUITE=<suite_name> is the test suite name. To compile PSA FF tests, use -DSUITE=IPC<br > 83- -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). 84- -DBUILD=<BUILD_DIR> : To select the build directory to keep output files. Default is BUILD/ inside current directory. 85- -DINCLUDE_PANIC_TESTS=<0|1> : The default compilation flow includes the functional API tests to build the test suite. It does not include panic tests that check for the API's PROGRAMMER ERROR(Panic) conditions as defined in the PSA-FF specification. You can include the panic tests for building the test suite by setting this option to 1. 86- -DPLATFORM_PSA_ISOLATION_LEVEL=<1|2|3> : PSA Firmware Framwork isolation level supported by the platform. Default is highest level of isolation which is three. 87- -DSP_HEAP_MEM_SUPP=<0|1> : Are dynamic memory functions available to secure partition? 0 means no and 1 means yes. This skips the secure partition dynamic memory functions related tests if this is marked as zero. 88- -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, If the system under test doesn't support the reboot of the system when it encounters the panic situation, a watchdog must be available to the tests if INCLUDE_PANIC_TESTS set to 1. 89- -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. 90- -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. 91- -DSPEC_VERSION=<spec_version> is test suite specification version. Which will build for given specified spec_version. Supported values for FF test suite are 1.0 and 1.1 . Default is empty. <br/> 92 If -DSPEC_VERSION option is not given it will build for latest version of testsuite. 93 For spec version corresponds test list will be in testsuite.db file in api-tests/ff/ipc/ folder. 94 Note: For FF 1.1 make sure to do the manifests changes and use SPEC_VERSION=1.1 . 95- -DSTATELESS_ROT_TESTS=<stateless_rot> is the flag for enabling stateless rot service for FF suite. Supported values are 0 and 1. 0 for connection based services and 1 for stateless rot services. 96 Note: For using STATELESS ROT service must use -DSPEC_VERSION = 1.1 . 97- -DPSA_INCLUDE_PATHS="<include_path1>;<include_path2>;...;<include_pathn>" is an additional directory to be included into the compiler search path. To compile IPC tests, the include path must point to the path where **psa/client.h**, **psa/service.h**, **psa/lifecycle.h** and test partition manifest output files(**psa_manifest/sid.h**, **psa_manifest/pid.h** and **psa_manifest/<manifestfilename>.h**) are located in your build system. Bydefault, PSA_INCLUDE_PATHS accepts absolute path. However, relative path can be provided using below format:<br /> 98``` 99 -DPSA_INCLUDE_PATHS=`readlink -f <relative_include_path>` 100``` 101 102For using FF-1.1 do the following manifests changes in api-tests/platform/manifests files. 103 Change "psa_framework_version" attribute from 1.0 to 1.1 in all manifests files. 104 Add "model": "IPC" attribute in manifests files. 105 Add "connection_based" attribute in all services of manifest file. Give value true or false accroding to your requirement. True for connection based services and false for stateless rot services. 106 Replace signal to name in irq attribute of manifest file. 107 108To compile IPC tests for **tgt_ff_tfm_an521** platform, execute the following commands: 109``` 110 cd api-tests 111 mkdir BUILD 112 cd BUILD 113 cmake ../ -G"Unix Makefiles" -DTARGET=tgt_ff_tfm_an521 -DCPU_ARCH=armv8m_ml -DSUITE=IPC -DPLATFORM_PSA_ISOLATION_LEVEL=2 -DSP_HEAP_MEM_SUPP=0 -DPSA_INCLUDE_PATHS="<include_path1>;<include_path2>;...;<include_pathn>" 114 cmake --build . 115``` 116**Note**: The default compilation flow includes the functional API tests to build the test suite. It does not include panic tests that check for the API's PROGRAMMER ERROR conditions as defined in the PSA-FF specification. You can include the panic tests for building the test suite just by passing **-DINCLUDE_PANIC_TESTS=1** to CMake. 117 118### Build output 119The test suite build generates the following binaries:<br /> 120 121NSPE libraries:<br /> 1221. **<build_dir>/val/val_nspe.a** 1232. **<build_dir>/platform/pal_nspe.a** 1243. **<build_dir>/ff/<suite_name>/test_combine.a** 125 126SPE libraries explicitly for IPC test suite:<br /> 1271. **<build_dir>/partition/driver_partition.a** 1282. **<build_dir>/partition/client_partition.a** 1293. **<build_dir>/partition/server_partition.a** 130 131### Integrating the libraries into your target platform 132 1331. Integrate the test partition (SPE archives) with your software stack containing SPM so that the partition code gets access to PSA-defined client and Secure partition APIs. This forms an SPE binary. 1342. Integrate **val_nspe.a**, **pal_nspe.a** and **test_combine.a** libraries with your Non-secure OS so that these libraries get access to PSA client APIs. This forms an NSPE binary. 1353. Load NSPE binary into Non-secure memory. 1364. Load SPE binary into Secure memory. 137 138## Test suite execution 139The following steps describe the execution flow before the test execution: <br /> 140 1411. The target platform must load the above binaries into appropriate memory. <br /> 1422. The *System Under Test* (SUT) boots to an environment that initializes the SPM and the test suite partitions are ready to accept requests. <br /> 1433. On the Non-secure side, the SUT boot software gives control to the test suite entry point **int32_t val_entry(void);** as an application entry point returning test status code. <br /> 1444. The tests are executed sequentially in a loop in the test_dispatcher function. <br /> 145 146For 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). 147 148## Security implication 149 150PSA FF 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 FF test suite is run on development platforms. If it is run on production system, make sure system is scrubbed after running the test suite. 151 152## License 153 154Arm PSA test suite is distributed under Apache v2.0 License. 155 156 157## Feedback, contributions, and support 158 159 - For feedback, use the GitHub Issue Tracker that is associated with this repository. 160 - For support, send an email to support-psa-arch-tests@arm.com with details. 161 - Arm licensees can contact Arm directly through their partner managers. 162 - Arm welcomes code contributions through GitHub pull requests. 163 164-------------- 165 166*Copyright (c) 2018-2022, Arm Limited and Contributors. All rights reserved.* 167
