| 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556 |
- ==================================
- Stack Safety Analysis
- ==================================
- Introduction
- ============
- The Stack Safety Analysis determines if stack allocated variables can be
- considered 'safe' from memory access bugs.
- The primary purpose of the analysis is to be used by sanitizers to avoid
- unnecessary instrumentation of 'safe' variables. SafeStack is going to be the
- first user.
- 'safe' variables can be defined as variables that can not be used out-of-scope
- (e.g. use-after-return) or accessed out of bounds. In the future it can be
- extended to track other variable properties. E.g. we plan to extend
- implementation with a check to make sure that variable is always initialized
- before every read to optimize use-of-uninitialized-memory checks.
- How it works
- ============
- The analysis is implemented in two stages:
- The intra-procedural, or 'local', stage performs a depth-first search inside
- functions to collect all uses of each alloca, including loads/stores and uses as
- arguments functions. After this stage we know which parts of the alloca are used
- by functions itself but we don't know what happens after it is passed as
- an argument to another function.
- The inter-procedural, or 'global', stage, resolves what happens to allocas after
- they are passed as function arguments. This stage performs a depth-first search
- on function calls inside a single module and propagates allocas usage through
- functions calls.
- When used with ThinLTO, the global stage performs a whole program analysis over
- the Module Summary Index.
- Testing
- =======
- The analysis is covered with lit tests.
- We expect that users can tolerate false classification of variables as
- 'unsafe' when in-fact it's 'safe'. This may lead to inefficient code. However, we
- can't accept false 'safe' classification which may cause sanitizers to miss actual
- bugs in instrumented code. To avoid that we want additional validation tool.
- AddressSanitizer may help with this validation. We can instrument all variables
- as usual but additionally store stack-safe information in the
- ``ASanStackVariableDescription``. Then if AddressSanitizer detects a bug on
- a 'safe' variable we can produce an additional report to let the user know that
- probably Stack Safety Analysis failed and we should check for a bug in the
- compiler.
|
