.../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=/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.*