Gary Morrison | ced8c6f | 2020-02-27 19:35:59 +0000 | [diff] [blame] | 1 | .../tf_fuzz directory contents: |
| 2 | |
| 3 | assets calls demo parser tests regression |
| 4 | backupStuff class_forwards.hpp lib README tf_fuzz.cpp utility |
| 5 | boilerplate commands Makefile template tf_fuzz.hpp visualStudio |
| 6 | |
| 7 | TF-Fuzz root directory. |
| 8 | |
| 9 | -------------------------------------------------------------------------------- |
| 10 | |
| 11 | TF-Fuzz is a TF-M fuzzing tool, at the PSA-call level. At the time of writing |
| 12 | this at least, presentations available at: |
| 13 | https://www.trustedfirmware.org/docs/TF-M_Fuzzing_Tool_TFOrg.pdf |
| 14 | https://zoom.us/rec/share/1dxZcZit111IadadyFqFU7IoP5X5aaa8gXUdr_UInxmMbyLzEqEmXQdx79-IWQ9p |
| 15 | (These presentation materials may not be viewable by all parties.) |
| 16 | |
| 17 | -------------------------------------------------------------------------------- |
| 18 | |
| 19 | To build TF-Fuzz, simply type "make" in this directory. Executable, called |
| 20 | "tfz," is placed in this directory. |
| 21 | |
| 22 | To run tfz, two environment variables must first be assigned. In bash syntax: |
| 23 | export TF_FUZZ_LIB_DIR=<path to this TF-M installation>/tools/tf_fuzz/lib |
| 24 | export TF_FUZZ_BPLATE=tfm_boilerplate.txt |
| 25 | |
| 26 | Examples of usage can be found in the demo directory. |
| 27 | |
| 28 | -------------------------------------------------------------------------------- |
| 29 | |
| 30 | To help understand the code, below is a C++-class hierarchy used in this code |
| 31 | base. They are explained further in the READMEs in their respective direc- |
| 32 | tories, so the file names where the classes are defined is listed below (this, |
| 33 | very roughly in order of functional interactions, of chronological usage during |
| 34 | execution, and of most-to-least importance): |
| 35 | |
| 36 | template_line ./template/template_line.hpp |
| 37 | sst_template_line ./template/template_line.hpp |
| 38 | read_sst_template_line ./template/sst_template_line.hpp |
| 39 | remove_sst_template_line ./template/sst_template_line.hpp |
| 40 | set_sst_template_line ./template/sst_template_line.hpp |
| 41 | policy_template_line ./template/template_line.hpp |
| 42 | read_policy_template_line ./template/crypto_template_line.hpp |
| 43 | set_policy_template_line ./template/crypto_template_line.hpp |
| 44 | key_template_line ./template/template_line.hpp |
| 45 | read_key_template_line ./template/crypto_template_line.hpp |
| 46 | remove_key_template_line ./template/crypto_template_line.hpp |
| 47 | set_key_template_line ./template/crypto_template_line.hpp |
| 48 | security_template_line ./template/template_line.hpp |
| 49 | security_hash_template_line ./template/secure_template_line.hpp |
| 50 | |
| 51 | psa_call ./calls/psa_call.hpp |
| 52 | crypto_call ./calls/psa_call.hpp |
| 53 | policy_call ./calls/crypto_call.hpp |
| 54 | policy_get_call ./calls/crypto_call.hpp |
| 55 | policy_set_call ./calls/crypto_call.hpp |
| 56 | key_call ./calls/crypto_call.hpp |
| 57 | get_key_info_call ./calls/crypto_call.hpp |
| 58 | set_key_call ./calls/crypto_call.hpp |
| 59 | destroy_key_call ./calls/crypto_call.hpp |
| 60 | sst_call ./calls/psa_call.hpp |
| 61 | sst_remove_call ./calls/sst_call.hpp |
| 62 | sst_get_call ./calls/sst_call.hpp |
| 63 | sst_set_call ./calls/sst_call.hpp |
| 64 | security_call ./calls/psa_call.hpp |
| 65 | hash_call ./calls/security_call.hpp |
| 66 | |
| 67 | boilerplate ./boilerplate/boilerplate.hpp |
| 68 | |
| 69 | psa_asset ./assets/psa_asset.hpp |
| 70 | crypto_asset ./assets/crypto_asset.hpp |
| 71 | policy_asset ./assets/crypto_asset.hpp |
| 72 | key_asset ./assets/crypto_asset.hpp |
| 73 | sst_asset ./assets/sst_asset.hpp |
| 74 | |
| 75 | tf_fuzz_info ./tf_fuzz.hpp |
| 76 | |
| 77 | crc32 ./utility/compute.hpp |
| 78 | |
| 79 | gibberish ./utility/gibberish.hpp |
| 80 | |
| 81 | expect_info ./utility/data_blocks.hpp |
| 82 | set_data_info ./utility/data_blocks.hpp |
| 83 | asset_name_id_info ./utility/data_blocks.hpp |
| 84 | |
| 85 | -------------------------------------------------------------------------------- |
| 86 | |
| 87 | There are currently two especially annoying warts on the design of TF-Fuzz: |
| 88 | * Need better management of variables in the generated code. Currently, |
| 89 | for example, upon "read"ing a value from a PSA asset more than once, it |
| 90 | creates a same-named (i.e., duplicate) variable for each such time, which |
| 91 | is obviously not right. |
| 92 | * Upon adding the ability to do "do any N of these PSA calls at random," |
| 93 | in hindsight, a fundamental flaw was uncovered in the top-level flow of |
| 94 | how TF-Fuzz generates the code. High-level summary: |
| 95 | * It should have completely distinct Parse, Simulate, then Code-generation |
| 96 | stages. |
| 97 | * Currently, the Parse and Simulate stages aren't really completely |
| 98 | distinct, so there's a bunch of complicated Boolean flags traffic- |
| 99 | copping between what in hindsight should be completely-separate Parse |
| 100 | vs. Code-generation functionality. |
| 101 | The function, interpret_template_line(), currently in |
| 102 | .../tf_fuzz/parser/tf_fuzz_grammar.y (which may be moved to the its own file |
| 103 | with randomize_template_lines()), has the lion's share of such Booleans, |
| 104 | such as fill_in_template, create_call_bool, and create_asset_bool. |
| 105 | The way it *should* work is: |
| 106 | * The parser in .../tf_fuzz_grammar.y should generate an STL vector (or |
| 107 | list) of psa_call-subclass "tracker" objects. It should not generate |
| 108 | PSA-asset tracker objects (subclasses of psa_asset). |
| 109 | * There should then be an organized Simulate stage, that sequences through |
| 110 | the psa_call-subclass list, creating and accumulating/maintaining current |
| 111 | state in psa_asset-subclass objects, using that current state to |
| 112 | determine expected results of each PSA call, which get annotated back |
| 113 | into the psa_call-tracker objects. |
| 114 | * Finally, there already is, and should continue to be, a Code-generation |
| 115 | phase that writes out the code, based upon text substitutions of |
| 116 | "boilerplate" code snippets. |
| 117 | * Currently, (hindsight obvious) the Parse and Simulate phases got somewhat |
| 118 | muddled together. This shouldn't be super-hard to fix. |
| 119 | That final Code-generation phase, conceptually at least, could be replaced |
| 120 | instead with simply executing those commands directly, for targets that |
| 121 | sufficient space to run TF-Fuzz in real-time. |
| 122 | |
| 123 | -------------- |
| 124 | |
| 125 | *Copyright (c) 2019-2020, Arm Limited. All rights reserved.* |