Mercurial > hg > CbC > CbC_llvm
comparison docs/StackSafetyAnalysis.rst @ 148:63bd29f05246
merged
| author | Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
|---|---|
| date | Wed, 14 Aug 2019 19:46:37 +0900 |
| parents | c2174574ed3a |
| children |
comparison
equal
deleted
inserted
replaced
| 146:3fc4d5c3e21e | 148:63bd29f05246 |
|---|---|
| 1 ================================== | |
| 2 Stack Safety Analysis | |
| 3 ================================== | |
| 4 | |
| 5 | |
| 6 Introduction | |
| 7 ============ | |
| 8 | |
| 9 The Stack Safety Analysis determines if stack allocated variables can be | |
| 10 considered 'safe' from memory access bugs. | |
| 11 | |
| 12 The primary purpose of the analysis is to be used by sanitizers to avoid | |
| 13 unnecessary instrumentation of 'safe' variables. SafeStack is going to be the | |
| 14 first user. | |
| 15 | |
| 16 'safe' variables can be defined as variables that can not be used out-of-scope | |
| 17 (e.g. use-after-return) or accessed out of bounds. In the future it can be | |
| 18 extended to track other variable properties. E.g. we plan to extend | |
| 19 implementation with a check to make sure that variable is always initialized | |
| 20 before every read to optimize use-of-uninitialized-memory checks. | |
| 21 | |
| 22 How it works | |
| 23 ============ | |
| 24 | |
| 25 The analysis is implemented in two stages: | |
| 26 | |
| 27 The intra-procedural, or 'local', stage performs a depth-first search inside | |
| 28 functions to collect all uses of each alloca, including loads/stores and uses as | |
| 29 arguments functions. After this stage we know which parts of the alloca are used | |
| 30 by functions itself but we don't know what happens after it is passed as | |
| 31 an argument to another function. | |
| 32 | |
| 33 The inter-procedural, or 'global', stage, resolves what happens to allocas after | |
| 34 they are passed as function arguments. This stage performs a depth-first search | |
| 35 on function calls inside a single module and propagates allocas usage through | |
| 36 functions calls. | |
| 37 | |
| 38 When used with ThinLTO, the global stage performs a whole program analysis over | |
| 39 the Module Summary Index. | |
| 40 | |
| 41 Testing | |
| 42 ======= | |
| 43 | |
| 44 The analysis is covered with lit tests. | |
| 45 | |
| 46 We expect that users can tolerate false classification of variables as | |
| 47 'unsafe' when in-fact it's 'safe'. This may lead to inefficient code. However, we | |
| 48 can't accept false 'safe' classification which may cause sanitizers to miss actual | |
| 49 bugs in instrumented code. To avoid that we want additional validation tool. | |
| 50 | |
| 51 AddressSanitizer may help with this validation. We can instrument all variables | |
| 52 as usual but additionally store stack-safe information in the | |
| 53 ``ASanStackVariableDescription``. Then if AddressSanitizer detects a bug on | |
| 54 a 'safe' variable we can produce an additional report to let the user know that | |
| 55 probably Stack Safety Analysis failed and we should check for a bug in the | |
| 56 compiler. |