Lines Matching refs:safe

14 the safe stack and the unsafe stack. The safe stack stores return addresses,
15 register spills, and local variables that are always accessed in a safe way,
18 on the safe stack.
36 used through multiple stack frames. Moving such objects away from the safe
56 changed to look for the live pointers on both safe and unsafe stacks.
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
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).
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
107 implementation in glibc), or store it in a safe region instead.
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
156 All local variables in functions with this attribute will be stored on the safe
157 stack. The safe stack remains unprotected against memory errors when accessing
159 accesses are safe. Furthermore, the addresses of such local variables should
188 on the safe stack before the call site, and restores it either after the