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