This is an archive of the discontinued LLVM Phabricator instance.

[asan] Default to -asan-use-private-alias=1
AbandonedPublic

Authored by MaskRay on Nov 25 2020, 12:19 AM.

Details

Summary

This enables private aliases on ELF/Mach-O/WebAssembly platforms even if
-fsanitize-address-use-odr-indicator is not specified.
Note that GCC also uses private aliases.

Pros: the following issues are fixed

  • Bogus The following global variable is not properly aligned. error for interposed global variables.

(PR37545 (this patch should allow us to restore D46665) and https://github.com/google/sanitizers/issues/1017)

Global variables of non-hasExactDefinition() linkages (i.e.
linkonce/linkonce_odr/weak/weak_odr/common/external_weak) are not instrumented.
If an instrumented variable gets interposed to an uninstrumented variable due to symbol
interposition (e.g. in PR37545, _ZTS1A in foo.so is resolved to _ZTS1A in the
executable), there may be a bogus error.

With private aliases, the register code will not resolve to a definition in another module,
and thus prevent the issue.

Similar to the above, but about an instrumented global variable gets interposed
to an uninstrumented global variable (not using address sanitizer) in another
module.

Cons:

  • vtable ODR issues due to interposition are no longer detectable, e.g. compiler-rt/test/asan/TestCases/Linux/odr_vtable.cpp
  • ODR issues due to mixed instrumented and non-instrumented globals (interposition) are no longer detectable, e.g. compiler-rt/test/asan/TestCases/Linux/odr_c_test.c
  • Can't catch overflows in globals relocated by R_*_COPY

(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016)
This affects -fno-pic and -fpie -mpie-copy-relocations.
However, -fpie (without -mpie-copy-relocations) produced code can still
catch the overflow.

// foo.so
int f[5] = {1};
// a.out
extern int f[5]; int main() { return f[5]; }
  • For ELF, minor object file size increases due to extra STT_SECTION

symbols in the symbol table (private aliases replace some relocations
referencing global symbols with .L symbols which are typically lower to
STT_SECTION symbols). The linked image usually has no size difference.

Diff Detail

Event Timeline

MaskRay created this revision.Nov 25 2020, 12:19 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptNov 25 2020, 12:19 AM
Herald added subscribers: llvm-commits, Restricted Project, hiraditya. · View Herald Transcript
MaskRay requested review of this revision.Nov 25 2020, 12:19 AM

I guess another cons was binary size increase? Would you like to run large scale testing on internal Google code?

MaskRay added a comment.EditedDec 2 2020, 10:46 AM

I guess another cons was binary size increase? Would you like to run large scale testing on internal Google code?

Did a large scale testing in internal Google code - tests passed.

For a linked shared object/executable, there is no size difference (checked with an asan clang). In object files, there are minimal differences:

% diff -U1 a.s b.s
--- a.s 2020-12-02 10:33:09.222518415 -0800
+++ b.s 2020-12-02 10:33:13.082528586 -0800
@@ -76,3 +76,3 @@
 __unnamed_1:
-       .quad   _ZN3foo1GE
+       .quad   .L__unnamed_2
        .quad   4                               # 0x4
@@ -92,2 +92,3 @@
        .quad   asan.module_dtor
+.set .L__unnamed_2, _ZN3foo1GE
        .ident  "clang version 12.0.0"
@@ -104 +105,2 @@
        .addrsig_sym __unnamed_1
+       .addrsig_sym .L__unnamed_2
  • Some global symbol referenced relocations are converted to reference local symbols. Using private aliases can cause some extra STT_SECTION symbols (for .data/.bss). The cost should be acceptable.
  • .llvm_addrsig: it may have additional entries for the extra STT_SECTION symbols (the encoding uses LEB128, so the increase is like one byte for each extra symbol)
MaskRay updated this revision to Diff 309058.Dec 2 2020, 2:19 PM
MaskRay edited the summary of this revision. (Show Details)

Fix two clang/test/CodeGen tests

Herald added a project: Restricted Project. · View Herald TranscriptDec 2 2020, 2:19 PM

https://reviews.llvm.org/D55156
So with this patch no code increase but we lose ODR checks.
To preserve checks we need -fsanitize-address-use-odr-indicator but then binary size increase.

alias change is LGTM, we can try to figure-out how to roll out -fsanitize-address-use-odr-indicator

compiler-rt/test/asan/TestCases/Linux/odr-vtable.cpp
16

now we don't test default behavior
can you add CHECKs for alias=1 as well?
same below

MaskRay updated this revision to Diff 309434.Dec 3 2020, 6:29 PM
MaskRay marked an inline comment as done.

Improve odr-vtable.cpp

vitalybuka added inline comments.Dec 4 2020, 12:18 PM
compiler-rt/test/asan/TestCases/Linux/odr-vtable.cpp
15–16

Is this going to work?

16

It was more about llvm/test/Instrumentation test

You just flipped to asan-use-private-alias=0 so we do not test =1. it was an issue before but now as with that as default we need to test it.

llvm/test/Instrumentation/AddressSanitizer/global_metadata.ll
1–4 ↗(On Diff #309058)
llvm/test/Instrumentation/AddressSanitizer/global_metadata_darwin.ll
4–6 ↗(On Diff #309058)
llvm/test/Instrumentation/AddressSanitizer/local_alias.ll
2–13

I didn't update FileCheck here

llvm/test/Instrumentation/AddressSanitizer/odr-check-ignore.ll
1–2 ↗(On Diff #309058)
MaskRay updated this revision to Diff 309675.Dec 4 2020, 3:09 PM
MaskRay marked 6 inline comments as done.
MaskRay edited the summary of this revision. (Show Details)

Pre-committed test improvement in 190b4374c00a9cf090ea73f9eddf3d8f71b11ec8
Rebase

compiler-rt/test/asan/TestCases/Linux/odr-vtable.cpp
15–16

Yes. -asan-use-odr-indicator=1 adds a named global symbol which can detect such issues.

vitalybuka added a subscriber: kcc.Dec 7 2020, 9:19 PM

I've chatted about that with @kcc and @eugenis . It seems the problem the patch is trying to solve is less important than regressions. Even with the current state when rare false ODR reports are possible it still useful.
It would be nice with -fsanitize-address-use-odr-indicator, but someone will need to figure-out what to do with few users broken by binary size increase.

vitalybuka requested changes to this revision.Apr 26 2021, 6:34 PM

I assume we are not moving forward with this patch?

This revision now requires changes to proceed.Apr 26 2021, 6:34 PM
MaskRay abandoned this revision.Nov 2 2022, 7:26 PM

Obsoleted by D137227