llvm.org GIT mirror llvm / d305cea
[stack-safety] Analysis documentation Summary: Basic documentation of the Stack Safety Analysis. It will be improved during review and upstream of an implementation. Reviewers: kcc, eugenis, vlad.tsyrklevich, glider Reviewed By: vlad.tsyrklevich Subscribers: arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D53336 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@347612 91177308-0d34-0410-b5e6-96231b3b80d8 Vitaly Buka 10 months ago
3 changed file(s) with 71 addition(s) and 0 deletion(s). Raw diff Collapse all Expand all
353353
354354 ``ScalarEvolution`` has a more complete understanding of pointer arithmetic
355355 than ``BasicAliasAnalysis``' collection of ad-hoc analyses.
356
357 ``-stack-safety``: Stack Safety Analysis
358 ------------------------------------------------
359
360 The ``StackSafety`` analysis can be used to determine if stack allocated
361 variables can be considered safe from memory access bugs.
362
363 This analysis' primary purpose is to be used by sanitizers to avoid unnecessary
364 instrumentation of safe variables.
356365
357366 ``-targetdata``: Target Data Layout
358367 -----------------------------------
0 ==================================
1 Stack Safety Analysis
2 ==================================
3
4
5 Introduction
6 ============
7
8 The Stack Safety Analysis determines if stack allocated variables can be
9 considered 'safe' from memory access bugs.
10
11 The primary purpose of the analysis is to be used by sanitizers to avoid
12 unnecessary instrumentation of 'safe' variables. SafeStack is going to be the
13 first user.
14
15 'safe' variables can be defined as variables that can not be used out-of-scope
16 (e.g. use-after-return) or accessed out of bounds. In the future it can be
17 extended to track other variable properties. E.g. we plan to extend
18 implementation with a check to make sure that variable is always initialized
19 before every read to optimize use-of-uninitialized-memory checks.
20
21 How it works
22 ============
23
24 The analysis is implemented in two stages:
25
26 The intra-procedural, or 'local', stage performs a depth-first search inside
27 functions to collect all uses of each alloca, including loads/stores and uses as
28 arguments functions. After this stage we know which parts of the alloca are used
29 by functions itself but we don't know what happens after it is passed as
30 an argument to another function.
31
32 The inter-procedural, or 'global', stage, resolves what happens to allocas after
33 they are passed as function arguments. This stage performs a depth-first search
34 on function calls inside a single module and propagates allocas usage through
35 functions calls.
36
37 When used with ThinLTO, the global stage performs a whole program analysis over
38 the Module Summary Index.
39
40 Testing
41 =======
42
43 The analysis is covered with lit tests.
44
45 We expect that users can tolerate false classification of variables as
46 'unsafe' when in-fact it's 'safe'. This may lead to inefficient code. However, we
47 can't accept false 'safe' classification which may cause sanitizers to miss actual
48 bugs in instrumented code. To avoid that we want additional validation tool.
49
50 AddressSanitizer may help with this validation. We can instrument all variables
51 as usual but additionally store stack-safe information in the
52 ``ASanStackVariableDescription``. Then if AddressSanitizer detects a bug on
53 a 'safe' variable we can produce an additional report to let the user know that
54 probably Stack Safety Analysis failed and we should check for a bug in the
55 compiler.
56
301301 PDB/index
302302 CFIVerify
303303 SpeculativeLoadHardening
304 StackSafetyAnalysis
304305
305306 :doc:`WritingAnLLVMPass`
306307 Information on how to write LLVM transformations and analyses.
436437
437438 :doc:`SpeculativeLoadHardening`
438439 A description of the Speculative Load Hardening mitigation for Spectre v1.
440
441 :doc:`StackSafetyAnalysis`
442 This document describes the design of the stack safety analysis of local
443 variables.
439444
440445 Development Process Documentation
441446 =================================