-
Notifications
You must be signed in to change notification settings - Fork 102
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Support for PSA Firmware Framework Test Suite. (#14)
- PSA IPC tests - PSA Crypto tests Signed-off-by: Jaykumar Pitambarbhai Patel <jaykumar.pitambarbhaipatel@arm.com>
- Loading branch information
1 parent
585abed
commit ea3cd06
Showing
366 changed files
with
27,012 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,131 @@ | ||
|
|
||
| # PSA Firmware Framework : Architecture Test Suite | ||
|
|
||
| ## Introduction | ||
|
|
||
| ### PSA FF Specification | ||
|
|
||
| Arm Platform Security Architecture (PSA) is a holistic set of threat models, security analysis, hardware and firmware architecture specifications, and an open source firmware reference implementation. PSA provides a recipe, based on industry best practice, that allows security to be consistently designed in, at both a hardware and firmware level. | ||
|
|
||
| The PSA Firmware Framework defines a standard programming environment and firmware interfaces for implementing and accessing security services within a device's Root of Trust. | ||
|
|
||
| The Firmware Framework specification: <br /> | ||
| - provides requirements for the SPM | ||
| - defines a standard runtime environment for developing protected RoT Services, including the programming interfaces | ||
| provided by the SPM for implementing and using RoT Services | ||
| - defines the standard interfaces for the PSA RoT Services. | ||
|
|
||
| To receive a copy of the PSA FF specification, Arm Licensees may contact Arm through their partner managers. | ||
|
|
||
| ### Architecture Test Suite | ||
|
|
||
| The Architecture Test Suite is a set of examples of the invariant behaviours that are specified by the PSA FF Specification. Use this suite to verify that these behaviours are implemented correctly in your system. | ||
|
|
||
| PSA FF Architecture Test Suite contains the tests that are self-checking, 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. | ||
|
|
||
| ## Release Update | ||
| - Release Version - 0.5 | ||
| - Code Quality: Alpha <br /> | ||
| This indicates the suite is in development and it contains tests which have not been validated on any platform. Please use this opportunity to suggest enhancements and point out errors. | ||
| - Current release contains the test suite for IPC and Crypto tests. | ||
| - 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. | ||
|
|
||
| ## Layers | ||
|
|
||
| PSA FF Architecture Test Suite uses a layered software-stack approach to enable porting across different test platforms. The constituents of the layered stack are: <br /> | ||
| - Test suite | ||
| - Validation Abstraction Layer (VAL) | ||
| - Platform Abstraction Layer (PAL) | ||
|
|
||
| The tests are written on top of Validation Abstraction Layer (VAL) and Platform Abstraction Layer (PAL). The abstraction layers provide platform information and runtime environment to enable execution of the tests. | ||
|
|
||
| In this release, PAL is written on top of baremetal drivers. It is expected that this layer will be ported to specific software stack of the platform. | ||
|
|
||
| ## Scenarios | ||
|
|
||
| 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](docs/) present in the docs/ folder. | ||
|
|
||
|
|
||
| ## Getting Started | ||
|
|
||
| Follow the instructions in the subsequent sections to get a copy of the source code on your local machine and build the tests. <br /> | ||
|
|
||
| ### Prerequisite | ||
|
|
||
| Before starting the test suite build, ensure that the following requirements are met: <br /> | ||
|
|
||
| - Host Operating System : Ubuntu 16.04 | ||
| - Scripting tools : Perl 5.12.3 | ||
| - Other open-source tools : GNU Arm Embedded Toolchain 6.3.1 | ||
|
|
||
| ### Download source | ||
| To download the master branch of the repository, type the following command: <br /> | ||
|
|
||
| git clone https://github.com/ARM-software/psa-arch-tests.git | ||
|
|
||
| ### Porting steps | ||
|
|
||
| Refer to the [Porting Guide](docs/Arm_PSA_FF_Arch_Test_Porting_Guide.md) document for porting steps. | ||
| Refer to the [Validation Methodology](docs/Arm_PSA_FF_Arch_Test_Validation_Methodology.pdf) document in the docs folder for additional details. | ||
|
|
||
| ### Build steps | ||
|
|
||
| To build PSA FF test suite for a given platform, execute the following commands: | ||
|
|
||
| 1. cd psa-ff | ||
| 2. ./tools/scripts/setup.sh --target <platform_name> --cpu_arch <cpu_architecture_version> --suite <suite_name> --build <build_dir> <br /> | ||
|
|
||
| Examples: <br /> | ||
| To compile IPC tests: ./tools/scripts/setup.sh --target fvp_mps2_cm4_mbedos --cpu_arch armv7m --suite ipc --include <include_path> --build BUILD_IPC <br /> | ||
| To compile Crypto tests: ./tools/scripts/setup.sh --target fvp_mps2_cm4_mbedos --cpu_arch armv7m --suite crypto --build BUILD_CRYPTO | ||
|
|
||
| <br /> where: | ||
|
|
||
| - <platform_name> is the same as the name of the target specific directory created in the platform/targets/ directory. <br /> | ||
| - <cpu_architecture_version> is the Arm Architecture version name for which compliance binaries should be compiled the binaries. For example, Armv7M, Armv8M-Baseline and Armv8M-Mainline Architecture. <br /> | ||
| - <suite_name> is the suite name and it is same as the suite name available in test_suites/ directory. <br /> | ||
| - <include_path> is an additional directory to be included into compiler search path. For IPC tests, it must point to path where psa_client.h and psa_service.h files are located. <br /> | ||
| - <build_dir> is an output directory to keep build files. | ||
|
|
||
| Refer ./tools/scripts/setup.sh --help to know more about options. | ||
|
|
||
| ### Build output | ||
| PSA FF test suite build generates following output binaries: | ||
|
|
||
| - <build_dir>/BUILD/val/val_nspe.a | ||
| - <build_dir>/BUILD/platform/pal_nspe.a | ||
| - <build_dir>/BUILD/<suite_name>/test_elf_combine.bin | ||
|
|
||
| ### Binaries integration into your platform | ||
|
|
||
| 1. Compile compliance tests partition code using your build tool. You must integrate compliance partition code with your software stack containing SPM so that partition code get access to PSA defined client and RoT service APIs. This forms a SPE binary. Refer to the [Porting Guide](docs/Arm_PSA_FF_Arch_Test_Porting_Guide.md) for more detail on compliance partition code compilation. | ||
| 2. Integrate BUILD/val/val_nspe.a and BUILD/platform/pal_nspe.a libraries with your Non-Secure OS so that these libraries get access to PSA client APIs. For Crypto tests, these libraries would require to get access to PSA Crypto APIs as well. This will form a NSPE binary. | ||
| 3. Load NSPE binary and test_elf_combine.bin to NS memory | ||
| 4. Load SPE binary into S memory | ||
|
|
||
| ## Test Suite Execution | ||
| The following steps describe the execution flow prior to the start of test execution: <br /> | ||
|
|
||
| 1. The target platform must load above binaries into appropriate memory. <br /> | ||
| 2. The System Under Test (SUT) would boot to an environment which intializes SPM and PSA FF partitions are ready to accept requests. <br /> | ||
| 3. On the non-secure side, the SUT - boot software would give control to the compliance tests entry point- *void val_entry(void);* as an application entry point. <br /> | ||
| 4. The tests are executed sequentially in a loop in the test_dispatcher function. <br /> | ||
|
|
||
| ## License | ||
|
|
||
| Arm PSA FF Architecture test suite is distributed under Apache v2.0 License. | ||
|
|
||
|
|
||
| ## Feedback, contributions, and support | ||
|
|
||
| - For feedback, use the GitHub Issue Tracker that is associated with this repository. | ||
| - For support, send an email to support-psa-arch-tests@arm.com with details. | ||
| - Arm licensees can contact Arm directly through their partner managers. | ||
| - Arm welcomes code contributions through GitHub pull requests. | ||
|
|
||
| -------------- | ||
|
|
||
| *Copyright (c) 2018, Arm Limited and Contributors. All rights reserved.* |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,100 @@ | ||
|
|
||
| # Porting Guide - PSA FF Architecture Test Suite | ||
| ----------------------------------------------------- | ||
|
|
||
| ## Introduction | ||
| The PSA FF Architecture test suite contains a platform abstraction layer (PAL) which abstracts platform specific information from the tests. | ||
| - The PAL layer interface functions need to be implemented/ported to the target platform. | ||
| - The target config file must be created/updated to match the details of the target platform. | ||
|
|
||
| This document provides details on the porting steps and the PAL APIs. | ||
|
|
||
| ## Porting steps | ||
|
|
||
| ### Target configuration | ||
|
|
||
| You must populate your system configuration and provide it as an input to test suite. | ||
|
|
||
| This is captured in a single static input configuration file that is named as target.cfg. This file is available at psa-ff/platform/targets/<platform_name>/. <br /> | ||
|
|
||
| An example of the input configuration file is as shown. | ||
|
|
||
| // UART device info | ||
| uart.num=1; | ||
| uart.0.base = 0x40004000; | ||
| uart.0.size = 0xFFF; | ||
| uart.0.intr_id = 0xFF; | ||
| uart.0.permission = TYPE_READ_WRITE; | ||
|
|
||
| // Watchdog device info | ||
| watchdog.num = 1; | ||
| watchdog.0.base = 0x40008000; | ||
| watchdog.0.size = 0xFFF; | ||
| watchdog.0.intr_id = 0xFF; | ||
| watchdog.0.permission = TYPE_READ_WRITE; | ||
|
|
||
| More details on the structure of the input can be obtained from val/nspe/val_target.h. | ||
|
|
||
| **Note**: | ||
| Test suite needs access to the following peripherals and the services of these peripherals are implemented as RoT services in the driver partition. | ||
| - One UART to print nspe and spe messages | ||
| - One Watchdog timer to help recovery from any fatal error conditions | ||
| - Non-volatile memory support to preserve test status over watchdog timer reset | ||
|
|
||
| ### Create a new target | ||
|
|
||
| Since PSA FF test suite is agnostic to various system targets, before building the tests, you must port the files mentioned in the following steps. | ||
|
|
||
| **Procedure** | ||
| ---------------- | ||
|
|
||
| - Create a new directory in platform/targets/<platform_name>. For reference, see the existing platform fvp_mps2_cm4_mbedos directory. | ||
| - Copy platform/targets/fvp_mps2_cm4_mbedos/target.cfg file into your <platform_name> folder and update it with your platform detail. Refer val/nspe/val_target.h for structure details. | ||
| - Update mmio_regions information available in platform/manifests/common/driver_partition_psa.json manifest file with your platform information. mmio_regions detail must match with device detail provided in the target.cfg file. | ||
| - The test suite specified "sid" and partition "id" are provided in manifest files available in platform/manifests/ directory. You can update them if they are clashing with your system defined sid and partition-id values. You may need to update platform/nspe/pal_sid.h file for any change in test suite provided SID values. | ||
| - Refer "PAL API list" section to view list of PAL API that must be ported for your target platform. These APIs definitions are available in nspe/pal_\*\_intf.c and spe/pal_\*_intf.c files. These APIs are written for fvp_mps2_cm4_mbedos platform. You can reuse the code if it works for your platform. Otherwise you must port them for your platform specific peripherals. | ||
| - Update platform/nspe/Makefile appropriately for platform/nspe/ code compilation. This make file is invoked as part of test suite build tool(./setup.sh) step and it creates <build_dir>/BUILD/platform/pal_nspe.a archive. | ||
| - The code available in platform/spe/ is part of driver partition and it must be compiled by your partition build tool by processing the platform/manifests/common/driver_partition_psa.json manifest file. See "Compiling compliance partition sources" section for more detail. | ||
|
|
||
| ## PAL API list | ||
| These functions will require implementation for the target platform. <br /> | ||
|
|
||
| - Following are the list of PAL APIs used in NSPE: <br /> | ||
|
|
||
| | No | Prototype | Description | Parameters | | ||
| |----|-----------------------------------------------------------|------------------------------------------------------|-------------------------------------| | ||
| | 01 | int pal_spi_read(addr_t addr, uint8_t *data, uint32_t len);| This function will read peripherals using SPI commands| addr : address of the peripheral<br/>data : read buffer<br/>len : length of the read buffer in bytes<br/>| | ||
| | 02 | void *pal_target_get_cfg_start(void); | provides the database source location. | void <br/> | | ||
| | 03 | uint32_t pal_crypto_function(int type, va_list valist); | This API will call the requested crypto function | type : function code<br/>valist : variable argument list<br/> | | ||
|
|
||
| - Following are the list of PAL APIs used in SPE: <br /> | ||
|
|
||
| | No | Prototype | Description | Parameters | | ||
| |----|-----------------------------------------------------------------------------------|-----------------------------------------------------------------------------------|----------------------------------------------------------| | ||
| | 01 | void pal_uart_init(addr_t uart_base_addr); | This function initializes the uart | uart_base_addr : Base address of the UART<br/> | | ||
| | 02 | void pal_print(char *str, uint32_t data); | This function parses the input string and writes byte by byte to print | str : Input String<br/>data : Value for Format specifier<br/> | | ||
| | 03 | int pal_wd_timer_init(addr_t base_addr, uint32_t time_us, uint32_t timer_tick_us);| Initializes an hardware watchdog timer | base_addr : Base address of the watchdog module<br/>time_us : Time in micro seconds<br/>timer_tick_us : Number of ticks per micro second<br/>| | ||
| | 04 | int pal_wd_timer_enable(addr_t base_addr); | Enables a hardware watchdog timer | base_addr : Base address of the watchdog module<br/> | | ||
| | 05 | int pal_wd_timer_disable(addr_t base_addr); | Disables a hardware watchdog timer | base_addr : Base address of the watchdog module<br/> | | ||
| | 06 | int pal_wd_timer_is_enabled(addr_t base_addr); | Checks whether hardware watchdog timer is enabled | base_addr : Base address of the watchdog module<br/> | | ||
| | 07 | int pal_nvmem_write(addr_t base, uint32_t offset, void *buffer, int size); | Writes 'size' bytes from buffer into non-volatile memory at a given 'base + offset'| base : Base address of NV MEM<br/>offset : Offset<br/>buffer : Pointer to source address<br/>size : Number of bytes<br/> | | ||
| | 08 | int pal_nvmem_read(addr_t base, uint32_t offset, void *buffer, int size); | Reads 'size' bytes from non-volatile memory at a given | base : Base address of NV MEM<br/>offset : Offset<br/>buffer : Pointer to source address<br/>size : Number of bytes<br/> | | ||
|
|
||
| ## Compiling compliance partition sources | ||
|
|
||
| - Your build tool must conform to manifest rules specified in PSA FF specification. Refer PSA FF specification for more details. | ||
| - The compliance required partition manifest files are available in platform/manifests/common and platform/manifests/ipc directory. Use these paths to search and process compliance provided partition manifest files using your build tool. | ||
| - Compliance partition source code requires your build tool to gererate following header files when your process the manifest files and those must be available when compiling partition source code: <br /> | ||
| - A private header file with \<manifestfilename.h\> naming convention per manifest containing macros that maps names to signals<br /> | ||
| - A global header file with \<psa_sid.h\> as name that contains SIDs macros of all manifests<br /> | ||
| - Your build tool must provide the implementation of PSA defined psa_client.h and psa_service.h header files to partition sources. | ||
| - Compliance partition source code includes header files with path relative to psa-ff directory. Therefore, when you compile the sources, your build tool must supply the full path of psa-ff directory to the compiler header file seach path. | ||
| - You must integrate compliance partition code with your software stack containing SPM so that partition code get access to PSA defined client and RoT service APIs. | ||
|
|
||
|
|
||
| ## License | ||
| Arm PSA FF Architecture test suite is distributed under Apache v2.0 License. | ||
|
|
||
| -------------- | ||
|
|
||
| *Copyright (c) 2018, Arm Limited and Contributors. All rights reserved.* |
Binary file not shown.
Oops, something went wrong.