blob: 020921935130dd5d4d4881665c84bd3729128850 [file] [log] [blame]
Raef Colesb3d343b2020-12-08 09:31:43 +00001#############
2FIH TEST TOOL
3#############
4
5This directory contains a tool for testing the fault injection mitigations
6implemented by TF-M.
7
8Description
9===========
10
11The tool relies on QEMU (simulating the AN521 target), and GDB.
12
13The tool will:
14 * first compile a version of TF-M with the given parameters.
15 * Then setup some infrastructure used for control of a QEMU session,
16 including a Virtual Hard Drive (VHD) to save test state and some FIFOs for
17 control.
18 * Then run GDB, which then creates a QEMU instance and attaches to it via the
19 GDBserver interface and the FIFOs.
20 * Run through an example execution of TF-M, conducting fault tests.
21 * Output a JSON file with details of which tests where run, and what failed.
22
23The workflow for actually running the test execution is as follows:
24 * Perform setup, including starting QEMU.
25 * Until the end_breakpoint is hit:
26 * Execute through the program until a `test_location` breakpoint is hit.
27 * Save the execution state to the QEMU VHD.
28 * Enable all the `critical point breakpoints`.
29 * Run through until the end_breakpoint to save the "known good" state. The
30 state saving is described below.
31 * For each of the fault tests specified:
32 * Load the test_start state, so that a clean environment is present.
33 * Perform the fault.
Jianliang Shenca50e362022-08-10 10:09:40 +080034 * Run through, evaluating any `critical memory` at every
35 `critical point breakpoint` and saving this to the test state.
Raef Colesb3d343b2020-12-08 09:31:43 +000036 * Detect any failure loop states, QEMU crashes, or the end breakpoint,
37 and end the test.
38 * Compare the execution state of the test with the "known good" state.
39 * Load the state at the start of the test.
40 * Disable all the `critical point breakpoints`.
41
42The output file will be inside the created TFM build directory. It is named
43`results.json` The name of the created TFM build dir will be determined by the
44build options. For example `build_GNUARM_debug_OFF_2/results.json`
45
46Dependencies
47============
48
49 * qemu-system-arm
50 * gdb-multiarch (with python3 support)
51 * python3.7+
52 * python packages detailed in requirements.txt
53
54The version of python packaged with gdb-multiarch can differ from the version of
55python that is shipped by the system. The version of python used by
56gdb-multiarch can can be tested by running the command:
57`gdb-multiarch -batch -ex "python import sys; print(sys.version)"`.
58If this version is not greater than or equal to 3.7, then gdb-multiarch may need
59to be upgraded. Under some distributions, this might require upgrading to a
60later version of the distribution.
61
62Usage of the tool
63=================
64
65Options can be determined by using
66
67``./fih_test --help``
68
69In general, executing `fih_test` from a directory inside the TF-M source
70directory (`<TFM_DIR>/build`), will automatically set the SOURCE_DIR and
71BUILD_DIR variables / arguments correctly.
72
73For example:
74```
75cd <TFM_DIR>
76mkdir build
77cd build
Jianliang Shen5375ddb2022-08-28 23:32:47 +080078<Path to>/fih_test -p LOW
79
80# Test with certain function
81<Path to>/fih_test -p LOW -l 2 -f "tfm_hal_set_up_static_boundaries"
82
83# Build the AXF file again if the source code has been changed
84<Path to>/fih_test -p LOW -l 2 -r
Raef Colesb3d343b2020-12-08 09:31:43 +000085```
86
87Fault types
88=====================
89
90The types of faults simulated is controlled by ``faults/__init__.py``. This file
91should be altered to change the fault simulation parameters. To add new fault
92types, new fault files should be added to the ``faults`` directory.
93
94Currently, the implemented fault types are:
95 * Setting a single register (from r0 to r15) to a random uint32
96 * Setting a single register (from r0 to r15) to zero
97 * Skipping between 1 and 7 instructions
98
99All of these will be run at every evaluation point, currently 40 faults per
100evaluation point.
101
102Working with results
103====================
104
105Results are written as a JSON file, and can be large. As such, it can be useful
106to employ dedicated tools to parse the JSON.
107
108The use of `jq <https://stedolan.github.io/jq/>` is highly recommended. Full
109documentation of this program is out of scope of this document, but instructions
110and reference material can be found at the linked webpage.
111
112For example, to find the amount of passes:
113
114``cat results.json | jq 'select(.passed==true) | .passed' | wc -l``
115
116And the amount of fails:
117
118``cat results.json | jq 'select(.passed==false) | .passed' | wc -l``
119
120To find all the faults that caused failures, and the information about where
121they occurred:
122
123``cat results.json | jq 'select(.passed==false) | {pc: .pc, file: .file, line: .line, asm: .asm, fault: .fault}'``
124
125--------------
126
Jianliang Shenca50e362022-08-10 10:09:40 +0800127*Copyright (c) 2021-2022, Arm Limited. All rights reserved.*