126 lines
6.8 KiB
Plaintext
126 lines
6.8 KiB
Plaintext
.../tf_fuzz directory contents:
|
|
|
|
assets calls demo parser tests regression
|
|
backupStuff class_forwards.hpp lib README tf_fuzz.cpp utility
|
|
boilerplate commands Makefile template tf_fuzz.hpp visualStudio
|
|
|
|
TF-Fuzz root directory.
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
TF-Fuzz is a TF-M fuzzing tool, at the PSA-call level. At the time of writing
|
|
this at least, presentations available at:
|
|
https://www.trustedfirmware.org/docs/TF-M_Fuzzing_Tool_TFOrg.pdf
|
|
https://zoom.us/rec/share/1dxZcZit111IadadyFqFU7IoP5X5aaa8gXUdr_UInxmMbyLzEqEmXQdx79-IWQ9p
|
|
(These presentation materials may not be viewable by all parties.)
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
To build TF-Fuzz, simply type "make" in this directory. Executable, called
|
|
"tfz," is placed in this directory.
|
|
|
|
To run tfz, two environment variables must first be assigned. In bash syntax:
|
|
export TF_FUZZ_LIB_DIR=<path to this TF-M installation>/tools/tf_fuzz/lib
|
|
export TF_FUZZ_BPLATE=tfm_boilerplate.txt
|
|
|
|
Examples of usage can be found in the demo directory.
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
To help understand the code, below is a C++-class hierarchy used in this code
|
|
base. They are explained further in the READMEs in their respective direc-
|
|
tories, so the file names where the classes are defined is listed below (this,
|
|
very roughly in order of functional interactions, of chronological usage during
|
|
execution, and of most-to-least importance):
|
|
|
|
template_line ./template/template_line.hpp
|
|
sst_template_line ./template/template_line.hpp
|
|
read_sst_template_line ./template/sst_template_line.hpp
|
|
remove_sst_template_line ./template/sst_template_line.hpp
|
|
set_sst_template_line ./template/sst_template_line.hpp
|
|
policy_template_line ./template/template_line.hpp
|
|
read_policy_template_line ./template/crypto_template_line.hpp
|
|
set_policy_template_line ./template/crypto_template_line.hpp
|
|
key_template_line ./template/template_line.hpp
|
|
read_key_template_line ./template/crypto_template_line.hpp
|
|
remove_key_template_line ./template/crypto_template_line.hpp
|
|
set_key_template_line ./template/crypto_template_line.hpp
|
|
security_template_line ./template/template_line.hpp
|
|
security_hash_template_line ./template/secure_template_line.hpp
|
|
|
|
psa_call ./calls/psa_call.hpp
|
|
crypto_call ./calls/psa_call.hpp
|
|
policy_call ./calls/crypto_call.hpp
|
|
policy_get_call ./calls/crypto_call.hpp
|
|
policy_set_call ./calls/crypto_call.hpp
|
|
key_call ./calls/crypto_call.hpp
|
|
get_key_info_call ./calls/crypto_call.hpp
|
|
set_key_call ./calls/crypto_call.hpp
|
|
destroy_key_call ./calls/crypto_call.hpp
|
|
sst_call ./calls/psa_call.hpp
|
|
sst_remove_call ./calls/sst_call.hpp
|
|
sst_get_call ./calls/sst_call.hpp
|
|
sst_set_call ./calls/sst_call.hpp
|
|
security_call ./calls/psa_call.hpp
|
|
hash_call ./calls/security_call.hpp
|
|
|
|
boilerplate ./boilerplate/boilerplate.hpp
|
|
|
|
psa_asset ./assets/psa_asset.hpp
|
|
crypto_asset ./assets/crypto_asset.hpp
|
|
policy_asset ./assets/crypto_asset.hpp
|
|
key_asset ./assets/crypto_asset.hpp
|
|
sst_asset ./assets/sst_asset.hpp
|
|
|
|
tf_fuzz_info ./tf_fuzz.hpp
|
|
|
|
crc32 ./utility/compute.hpp
|
|
|
|
gibberish ./utility/gibberish.hpp
|
|
|
|
expect_info ./utility/data_blocks.hpp
|
|
set_data_info ./utility/data_blocks.hpp
|
|
asset_name_id_info ./utility/data_blocks.hpp
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
There are currently two especially annoying warts on the design of TF-Fuzz:
|
|
* Need better management of variables in the generated code. Currently,
|
|
for example, upon "read"ing a value from a PSA asset more than once, it
|
|
creates a same-named (i.e., duplicate) variable for each such time, which
|
|
is obviously not right.
|
|
* Upon adding the ability to do "do any N of these PSA calls at random,"
|
|
in hindsight, a fundamental flaw was uncovered in the top-level flow of
|
|
how TF-Fuzz generates the code. High-level summary:
|
|
* It should have completely distinct Parse, Simulate, then Code-generation
|
|
stages.
|
|
* Currently, the Parse and Simulate stages aren't really completely
|
|
distinct, so there's a bunch of complicated Boolean flags traffic-
|
|
copping between what in hindsight should be completely-separate Parse
|
|
vs. Code-generation functionality.
|
|
The function, interpret_template_line(), currently in
|
|
.../tf_fuzz/parser/tf_fuzz_grammar.y (which may be moved to the its own file
|
|
with randomize_template_lines()), has the lion's share of such Booleans,
|
|
such as fill_in_template, create_call_bool, and create_asset_bool.
|
|
The way it *should* work is:
|
|
* The parser in .../tf_fuzz_grammar.y should generate an STL vector (or
|
|
list) of psa_call-subclass "tracker" objects. It should not generate
|
|
PSA-asset tracker objects (subclasses of psa_asset).
|
|
* There should then be an organized Simulate stage, that sequences through
|
|
the psa_call-subclass list, creating and accumulating/maintaining current
|
|
state in psa_asset-subclass objects, using that current state to
|
|
determine expected results of each PSA call, which get annotated back
|
|
into the psa_call-tracker objects.
|
|
* Finally, there already is, and should continue to be, a Code-generation
|
|
phase that writes out the code, based upon text substitutions of
|
|
"boilerplate" code snippets.
|
|
* Currently, (hindsight obvious) the Parse and Simulate phases got somewhat
|
|
muddled together. This shouldn't be super-hard to fix.
|
|
That final Code-generation phase, conceptually at least, could be replaced
|
|
instead with simply executing those commands directly, for targets that
|
|
sufficient space to run TF-Fuzz in real-time.
|
|
|
|
--------------
|
|
|
|
*Copyright (c) 2019-2020, Arm Limited. All rights reserved.*
|