blob: fadedf07ca589ac6dbb33ec81c5a1bc8f134e267 [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:
Jianliang Shen5375ddb2022-08-28 23:32:47 +080074
Elena Uziunaiteb90a3402023-11-13 16:24:28 +000075.. code-block:: console
Jianliang Shen5375ddb2022-08-28 23:32:47 +080076
Elena Uziunaiteb90a3402023-11-13 16:24:28 +000077 cd <TFM_DIR>
78 mkdir build
79 cd build
80 <Path to>/fih_test -p LOW
81
82 # Test with certain function
83 <Path to>/fih_test -p LOW -l 2 -f "tfm_hal_set_up_static_boundaries"
84
85 # Build the AXF file again if the source code has been changed
86 <Path to>/fih_test -p LOW -l 2 -r
Raef Colesb3d343b2020-12-08 09:31:43 +000087
88Fault types
89=====================
90
91The types of faults simulated is controlled by ``faults/__init__.py``. This file
92should be altered to change the fault simulation parameters. To add new fault
93types, new fault files should be added to the ``faults`` directory.
94
95Currently, the implemented fault types are:
96 * Setting a single register (from r0 to r15) to a random uint32
97 * Setting a single register (from r0 to r15) to zero
98 * Skipping between 1 and 7 instructions
99
100All of these will be run at every evaluation point, currently 40 faults per
101evaluation point.
102
103Working with results
104====================
105
106Results are written as a JSON file, and can be large. As such, it can be useful
107to employ dedicated tools to parse the JSON.
108
109The use of `jq <https://stedolan.github.io/jq/>` is highly recommended. Full
110documentation of this program is out of scope of this document, but instructions
111and reference material can be found at the linked webpage.
112
113For example, to find the amount of passes:
114
115``cat results.json | jq 'select(.passed==true) | .passed' | wc -l``
116
117And the amount of fails:
118
119``cat results.json | jq 'select(.passed==false) | .passed' | wc -l``
120
121To find all the faults that caused failures, and the information about where
122they occurred:
123
124``cat results.json | jq 'select(.passed==false) | {pc: .pc, file: .file, line: .line, asm: .asm, fault: .fault}'``
125
126--------------
127
Jianliang Shenca50e362022-08-10 10:09:40 +0800128*Copyright (c) 2021-2022, Arm Limited. All rights reserved.*