[TA] Analyze out-of-BT func with tainted parameters #1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This patch introduces support for analysis of functions, which call site is not in the backtrace, if the parameter is tainted. For now, only parameters forwarded through registers are supported.
This partially resolves cisco-open#36
Description
To be able to track the value of function parameters, this patch introduces forward TaintAnalysis, which propagates the Taint from the function entry point to the point where the parameter value is set. If the path of the Taint is not terminated in the call (it is not set to constant value like in the tainted-param-inside-blame.test ), we should run the backward TaintAnalysis to try to propagate the Taint from the point where the parameter is set to a value, to the point where that value is set to constant ( tainted-params-outside-blame.test ).
Content of commits
0001-Target-Helpers-for-param-forwarding-registers.patch
0002-TaintDFG-Upgrade-TaintDFG-infrastructure.patch
0003-TA-Detect-tainted-parameters.patch
0004-TA-Introduce-forward-Taint-Analysis.patch
(like runOnBlameMF, but simplified, and in the forward direction)
Idea is to propagate the Taint from parameter (function entry point) to the
program point, where the parameter's value is set.
(Simplified version of propagateTaint, but in the oposite (forward) direction)
is not empty, we run the Backward Analysis
(that covers cases where the parameter is set in the call, or if it gets value from another parameter)
0005-TA-Analysis-of-already-decompiled-functions.patch
(so crash-start is not at the expected place as for other out of the BT calls)
0006-New-tests-for-tainted-params-analysis.patch
0007 Addressing comments 1
0008 [TA] Support parameters on the stack
isStackSlotTainted
method to check for Tainted stack slots and populating TaintList to be used in the TaintAnalysis of the calleetransformSPtoBPTaints
method to transform TaintInfo to use BP as the base instead of SP, to match the callee frame pointer, when the callee is analyzedtransformBPtoSPTaints
method to transform TaintInfo to use SP as the base instead of BP, to match the caller stack pointer, after callee is analyzedrunOnBlameMF
to properly setupTL_Of_Call
to be used during TaintAnalysis of calls out of the backtrace, when parameters are taintedExample
Run crash analyzer:
llvm-crash-analyzer --print-potential-crash-cause-loc ./m --core-file core.m
Output:
TaintDFG:
Ported from cisco-open PR #47