Lines Matching full:stack

12 based on stack buffer overflows, without introducing any measurable performance
13 overhead. It works by separating the program stack into two distinct regions:
14 the safe stack and the unsafe stack. The safe stack stores return addresses,
16 while the unsafe stack stores everything else. This separation ensures that
17 buffer overflows on the unsafe stack cannot be used to overwrite anything
18 on the safe stack.
30 stack and, hence, do not need unsafe stack frames to be created. The cost of
31 creating unsafe stack frames for large functions is amortized by the cost of
35 being moved to the unsafe stack are usually large arrays or variables that are
36 used through multiple stack frames. Moving such objects away from the safe
37 stack increases the locality of frequently accessed values on the stack, such
53 Certain code that relies on low-level stack manipulations requires adaption to
63 Signal handlers that use ``sigaltstack()`` must not use the unsafe stack (see
64 ``__attribute__((no_sanitize("safe-stack")))`` below).
72 are always accessed in a safe way by separating them in a dedicated safe stack
73 region. The safe stack is automatically protected against stack-based buffer
74 overflows, since it is disjoint from the unsafe stack in memory, and it itself
75 is always accessed in a safe way. In the current implementation, the safe stack
77 randomization and information hiding: the safe stack is allocated at a random
78 address and the instrumentation ensures that no pointers to the safe stack are
79 ever stored outside of the safe stack itself (see limitations below).
86 that are stored on the heap or the unsafe stack, such as `CPI
93 the unsafe stack and cause a program to call arbitrary location, which in turn
94 might enable stack pivoting and return-oriented programming.
97 stack-based buffer overflows, but protection against arbitrary memory write
100 its known security limitations. The safe stack pointer hiding is not perfect
103 low-level bugs in runtime support could leak the safe stack pointer. In the
105 prevented by adjusting such functions to either encrypt the stack pointer when
110 stronger safe stack protection mechanisms, that rely on software fault
123 To enable SafeStack, just pass ``-fsanitize=safe-stack`` flag to both compile
147 ``__attribute__((no_sanitize("safe-stack")))``
150 Use ``__attribute__((no_sanitize("safe-stack")))`` on a function declaration
151 to specify that the safe stack instrumentation should not be applied to that
152 function, even if enabled globally (see ``-fsanitize=safe-stack`` flag). This
154 exact layout of their stack frames.
157 stack. The safe stack remains unprotected against memory errors when accessing
165 This builtin function returns current unsafe stack pointer of the current
171 This builtin function returns a pointer to the start of the unsafe stack of the
187 sites. Specifically, the instrumentation pass saves the shadow stack pointer
188 on the safe stack before the call site, and restores it either after the