Before running any scripts, ensure the LLVM_BUILD_DIR
environment variable is set correctly:
For instance: export LLVM_BUILD_DIR=~/llvm-project/build
These environment variables are used by the scripts to locate the LLVM build directory and the AutoPatch source code directory.
Also, please check the directory of the variables used in the scripts, and make sure they are correct for your PC. For instance, please make sure AUTOPATCH_INSTRUMENT_REPO
and AUTOPATCH_ANALYSIS_REPO
is set to the folder that contains our LLVM Passes (Default: ~/AutoPatchWorkspace/Passes/
)
instrument.sh
generates the instrumented LLVM IR for the input C file. First, it uses LLVM's clang to generate the LLVM IR for the file. After that, it builds the LLVM project with the AutoPatchFirstPass pass by using ninja
. Finally, using LLVM's opt, it runs the AutoPatchFirstPass pass on the generated LLVM IR to produce the instrumented LLVM IR.
Run instrument.sh
in the shell with the input C file (e.g., the C file including the patched function) as the argument. The script will then ask whether or not it is a patched function. If it is, provide the line numbers containing the patch. Then, it asks if you have used a new function in the patch or not. Finally, it generates two outputs with two different types (.ll and .bc) at the same location as the instrumented file.
analysis.sh
generates the executable object file targetting specific hardware. First, using ninja
it builds LLVM with the AutoPatchSecondPass pass. Then, it runs the AutoPatchSecondPass pass on the instrumented LLVM IR to produce a new LLVM IR file. Finally, compiling using LLVM's clang, it generates the executable object file.
Execute analysis.sh
in the shell. Provide the path to the .bc
IR file generated by instrument.sh
. Provide the name of the patched function, along with the line numbers within the source code. Indicate whether the patch introduces a filter
, which adds additional checking logic, or a replace
, which introduces new logic or replaces existing code. Further, indicate whether the patch is of type redirect
, drop
, or none
. redirect
indicates that control-flow returns to the different address if the hotpatch detects a malicious input. drop
will return to caller of the vulnerable function. Finally, none
indicates control-flow continues as is. Finally, provide the CVE-id, which will name the directory of the object file will be placed in and the function name of generated hotpatch.
This script generates three different types of files (.ll, .bc, .o) in HOTPATCH_DIRECTORY (Default: ~/AutoPatchWorkspace/Testcases/Results/
).