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