Page MenuHomePhabricator

[compiler-rt] Intercept the uname() function

Authored by iii on Mar 22 2020, 3:47 PM.



Move interceptor from msan to, so that
other sanitizers could benefit.

Adjust FixedCVE_2016_2143() to deal with the intercepted uname().

Patch by Ilya Leoshkevich.

Diff Detail

Event Timeline

iii created this revision.Mar 22 2020, 3:47 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 22 2020, 3:47 PM
Herald added subscribers: Restricted Project, krytarowski, dberris. · View Herald Transcript
vitalybuka accepted this revision.Mar 22 2020, 7:20 PM
vitalybuka added inline comments.

please use separate

This revision is now accepted and ready to land.Mar 22 2020, 7:20 PM
iii updated this revision to Diff 251981.Mar 23 2020, 3:49 AM


eugenis accepted this revision.Mar 23 2020, 11:44 AM
vitalybuka edited the summary of this revision. (Show Details)Mar 23 2020, 12:59 PM
This revision was automatically updated to reflect the committed changes.
pcc added a subscriber: pcc.Mar 26 2020, 12:31 PM

This change broke the sanitizer-x86_64-linux bot:
Please take a look.

Unfortunately I was unable to reproduce locally (Debian testing) and was only able to reproduce on the bot itself (which runs Debian stretch set up using this script:
). Vitaly probably knows more about how the bot was set up if you have trouble reproducing.

iii added a comment.Mar 26 2020, 12:49 PM

I'll check. I was hoping this was already fixed by, but the last build already contains that commit, and yet it still fails with the same symptoms.

iii added a comment.EditedMar 26 2020, 7:36 PM

I've installed stretch and hit the following issue:

Program received signal SIGILL, Illegal instruction.
0xf7ddab52 in _xbegin () at ../sysdeps/unix/sysv/linux/x86/hle.h:53
53	  asm volatile (".byte 0xc7,0xf8 ; .long 0" : "+a" (ret) :: "memory");
(gdb) bt
#0  0xf7ddab52 in _xbegin () at ../sysdeps/unix/sysv/linux/x86/hle.h:53
#1  __GI___pthread_rwlock_rdlock (rwlock=<optimized out>) at pthread_rwlock_rdlock.c:128
#2  0xf7c12964 in __dcigettext (domainname=0xf7d4cfd8 <_libc_intl_domainname> "libc", msgid1=0xf6103970 "undefined symbol: swift_demangle", msgid2=0x0, plural=0, n=0, category=5) at dcigettext.c:527
#3  0xf7c115e6 in __GI___dcgettext (domainname=0xf7d4cfd8 <_libc_intl_domainname> "libc", msgid=0xf6103970 "undefined symbol: swift_demangle", category=5) at dcgettext.c:47
#4  0xf7dc31d9 in __dlerror () at dlerror.c:94
#5  0x08135e70 in __sanitizer::InitializeSwiftDemangler () at $HOME/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_posix_libcdep.cpp:75
#6  __sanitizer::Symbolizer::LateInitialize () at $HOME/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_posix_libcdep.cpp:482
#7  0x0810eb32 in __asan::AsanInitInternal () at $HOME/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:521
#8  0x0810ec80 in __asan::AsanInitInternal () at $HOME/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:538
#9  __asan::AsanInitFromRtl () at $HOME/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:537
#10 0x08091b0d in __interceptor_uname (utsname=0xffffd350) at $HOME/llvm-project/compiler-rt/lib/asan/../sanitizer_common/
#11 0xf7dd4ed7 in is_smp_system () at ../sysdeps/unix/sysv/linux/i386/smp.h:39
#12 __pthread_initialize_minimal_internal () at nptl-init.c:487
#13 0xf7dd43d8 in _init () at ../sysdeps/i386/crti.S:74
#14 0x00000000 in ?? ()

The problem is that libc calls uname() very early - earlier than it finds out hardware capabilities (in this case: whether lock elision is available).
COMMON_INTERCEPTOR_ENTER, however, triggers usage of functions that use these capabilities.
I think the solution should be to avoid calling ENSURE_ASAN_INITED in COMMON_INTERCEPTOR_ENTER for uname().
Something like this seems to be already implemented for macOS:

if (SANITIZER_MAC && UNLIKELY(!asan_inited))                               \
  return REAL(func)(__VA_ARGS__);                                          \