[llvm-bugs] [Bug 46300] New: AddressSanitizer globals instrumentation causes ELF info to change size of symbol

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Jun 12 04:10:30 PDT 2020


https://bugs.llvm.org/show_bug.cgi?id=46300

            Bug ID: 46300
           Summary: AddressSanitizer globals instrumentation causes ELF
                    info to change size of symbol
           Product: compiler-rt
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: asan
          Assignee: unassignedbugs at nondot.org
          Reporter: elver at google.com
                CC: llvm-bugs at lists.llvm.org

When instrumenting globals, ASan adds redzones by replacing the globals with a
new one that has the redzones added to them. LLVM then, correctly, coveys this
information as-is and the global symbol will show up with the new size in ELF
(and likely other binary formats) symbol information.

This may cause problems for programs that somehow scan other binaries' symbol
information and rely on the usable (without redzone) size to be presented only.

This was first caught in: https://github.com/ClangBuiltLinux/linux/issues/1045

To fix, we need to ensure that global variables' symbol information will show
up in ELF symbol tables like they would without ASan instrumentation, i.e.
hiding the fact that there is a redzone.

Evgenii Stepanov suggests:

> target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
> target triple = "x86_64-unknown-linux-gnu"
> 
> @x_ = private global i64 0, align 8
> @y_ = private global i64 0, align 8
> 
> @x = dso_local alias i32, bitcast (i64* @y_ to i32*)
> module asm ".size x, 4"
> @y = dso_local alias i32, bitcast (i64* @y_ to i32*)
> module asm ".size y, 4"
> 
> Alternatively, we could build a way to communicate the desired symbol size to the MC layer. It could use metadata, or maybe we could even make aliases emit .size directives unconditionally.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200612/4b3421a7/attachment.html>


More information about the llvm-bugs mailing list