blob: 646b0bfdb2c92d95e73936d5b409794b44e62143 [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
78<Path to>/fih_test -f LOW
79```
80
81Fault types
82=====================
83
84The types of faults simulated is controlled by ``faults/__init__.py``. This file
85should be altered to change the fault simulation parameters. To add new fault
86types, new fault files should be added to the ``faults`` directory.
87
88Currently, the implemented fault types are:
89 * Setting a single register (from r0 to r15) to a random uint32
90 * Setting a single register (from r0 to r15) to zero
91 * Skipping between 1 and 7 instructions
92
93All of these will be run at every evaluation point, currently 40 faults per
94evaluation point.
95
96Working with results
97====================
98
99Results are written as a JSON file, and can be large. As such, it can be useful
100to employ dedicated tools to parse the JSON.
101
102The use of `jq <https://stedolan.github.io/jq/>` is highly recommended. Full
103documentation of this program is out of scope of this document, but instructions
104and reference material can be found at the linked webpage.
105
106For example, to find the amount of passes:
107
108``cat results.json | jq 'select(.passed==true) | .passed' | wc -l``
109
110And the amount of fails:
111
112``cat results.json | jq 'select(.passed==false) | .passed' | wc -l``
113
114To find all the faults that caused failures, and the information about where
115they occurred:
116
117``cat results.json | jq 'select(.passed==false) | {pc: .pc, file: .file, line: .line, asm: .asm, fault: .fault}'``
118
119--------------
120
Jianliang Shenca50e362022-08-10 10:09:40 +0800121*Copyright (c) 2021-2022, Arm Limited. All rights reserved.*