viralcode / memory-sanitizer Goto Github PK

Stack allocations are poisoned even in blacklisted functions. If a pointer to 
such allocation is passed to a non-blacklisted function, we are in trouble.

1. Disable fcvt interceptor
2. run "./msan_test --gtest_filter=*fcvt " under msandr 
3. observe a false positive 

We initialize byval argument shadow in getShadow(arg).
With -msan-check-access-address=0 it is possible (and very likely) that byval 
argument value is accessed without ever calling that.

Luckily, msan-check-access-address=1 is the default.

I tried to run it with unit_tests natively and see a segfault:

Program received signal SIGSEGV, Segmentation fault.
0x00007f5e9330f4eb in __msan_init () at 
../projects/compiler-rt/lib/msan/msan.cc:287
287     ../projects/compiler-rt/lib/msan/msan.cc: No such file or directory.

(gdb) x/10i 0x7f5e9330f4e0
   0x7f5e9330f4e0 <__msan_init()>:      push   %r15
   0x7f5e9330f4e2 <__msan_init()+2>:    push   %r14
   0x7f5e9330f4e4 <__msan_init()+4>:    push   %r12
   0x7f5e9330f4e6 <__msan_init()+6>:    push   %rbx
   0x7f5e9330f4e7 <__msan_init()+7>:    sub    $0x28,%rsp
=> 0x7f5e9330f4eb <__msan_init()+11>:   cmpl   $0x0,-0x6f58c672(%rip)        # 
0x7f5e23d82e80
   0x7f5e9330f4f2 <__msan_init()+18>:   jne    0x7f5e9330f7ba <__msan_init()+730>
   0x7f5e9330f4f8 <__msan_init()+24>:   movb   $0x1,-0x6f58c67b(%rip)        # 0x7f5e23d82e84
   0x7f5e9330f4ff <__msan_init()+31>:   lea    0x65af3fcc(%rip),%rax        # 0x7f5ef8e034d2 <.L.str4>
   0x7f5e9330f506 <__msan_init()+38>:   mov    0x6a5297f3(%rip),%rcx        # 0x7f5efd838d00

(gdb) info proc map
process 1481
Mapped address spaces:

          Start Addr           End Addr       Size     Offset objfile
      0x7f5e84f93000     0x7f5e84f98000     0x5000        0x0 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
      0x7f5e84f98000     0x7f5e85197000   0x1ff000     0x5000 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
      0x7f5e85197000     0x7f5e85198000     0x1000     0x4000 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0

It seems there is no memory at 0x7f5e23d82e80


In a different run:
It looks like the the address calcuation is wrong? the whole executable seems 
is there.
(gdb) x/10i __msan_init
   0x7f11e33b84e0 <__msan_init()>:      push   %r15
   0x7f11e33b84e2 <__msan_init()+2>:    push   %r14
   0x7f11e33b84e4 <__msan_init()+4>:    push   %r12
   0x7f11e33b84e6 <__msan_init()+6>:    push   %rbx
   0x7f11e33b84e7 <__msan_init()+7>:    sub    $0x28,%rsp
=> 0x7f11e33b84eb <__msan_init()+11>:   cmpl   $0x0,-0x6f58c672(%rip)        # 
0x7f1173e2be80

(gdb) info proc mapping
process 32642
Mapped address spaces:

          Start Addr           End Addr       Size     Offset objfile
      0x7f11d503c000     0x7f11d5041000     0x5000        0x0 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
      ...
      0x7f11e2893000     0x7f124d426000 0x6ab93000        0x0 /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Debug/unit_tests
      0x7f124d426000     0x7f124d90c000   0x4e6000 0x6ab92000 /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Debug/unit_tests
      0x7f124d90c000     0x7f1273e2c000 0x26520000 0x6b078000 /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Debug/unit_tests
      0x7f1273e2c000     0x7f12762c2000  0x2496000        0x0
      0x7fff905ca000     0x7fff905eb000    0x21000        0x0 [stack]
      0x7fff905ff000     0x7fff90600000     0x1000        0x0 [vdso]
    0xffffffffff600000 0xffffffffff601000     0x1000        0x0 [vsyscall]

getpwuid_r and friends

lib/msan/lit_tests/dtls_test.c currently produces a false report
because we don't know the dynamic tls and don't clean its shadow on thread exit.

The behavior is different with glibs < 2.19 and >= 2.19,
see https://groups.google.com/forum/#!topic/address-sanitizer/BfwYD8HMxTM
With < 2.19 dtls will be created by malloc and thus will be poisoned,
with >= 2.19 dtls will be created by mmap and this will not be poisoned,
but we still must unpoison it on thread exit.

We'l need to use the new __tls_get_addr interceptor machinery 
to clean shadow for dtls on its creation and on thread exit.

Most of the code is already there 
(lib/sanitizer_common/sanitizer_tls_get_addr.h)

What steps will reproduce the problem?
1. I compiled DynamoRIO and DrMemory accoring to msandr/README.txt
2. For llvm I tool the release branch (3.3.1)
3. I compiled a simple hello world with -O1 -fsanitize=memory
4. Without drrun the binary runs fine
5. With drrun (with debug) I get:

<Application /home/rschulz/download/gromacs5.0/clang/a.out (5795).  
Unrecoverable Error at PC 0x0000000077008d41.  Program aborted. 
Received SIGSEGV at pc 0x0000000077008d41 in thread 5795
Base: 0x0000000071000000
Registers: eax=0x0000000000000000 ebx=0x0000000000000000 ecx=0x00000000712a075b 
edx=0x00000000772351c0
        esi=0x0000000000000010 edi=0x00007f0371c8a080 esp=0x00007f0371caed00 ebp=0x0000000000000001
        r8 =0x0000000000000001 r9 =0x0000000000000000 r10=0x00000000712a075b r11=0x0000000000000246
        r12=0x00007f0371c8a080 r13=0x0000000000000005 r14=0x0000000000000000 r15=0x00007fff5a0c0048
        eflags=0x0000000000010202
version 4.1.2379, custom build
-no_dynamic_options -client_lib 
'/home/rschulz/software/llvm/lib/clang/3.3.1/lib/linux/libclang_rt.msandr-x86_64
.so;0;' -code_api -stack_size 56K -max_elide_jmp 0 -max_elide_call 0 
-no_inline_ignored_syscalls -native_exec_default_list '' 
-no_native_exec_managed_code -no_indcall2direct >

Do I have to use a specific version of DynamoRIO with 3.3.1?

I didn't know whether I should ask here or at DynamoRIO. Also I couldn't find a 
memory-sanitizer mailinglist so I hope opening an issue is OK.

subj
please cover the major kinds of output

This would require reusing ThreadRegistry machinery in MSan.

Code in insertCheck() does nothing when shadow is not an Instruction.
This fails to add a check when shadow is a compile-time constant.

At a high enough optimization level, it fails the following positive test:

int* p = malloc(int);
volatile int x = *p;

(*p) is compile-time (undef) value.

Handle SIMD stores at least to avoid false positives.

% cat z.cc
void bar();
void zoo() throw() {
  bar();
}

% clang -c -fmemory-sanitizer -O2 z.cc


clang: /home/kcc/memory-sanitizer/llvm/lib/VMCore/Type.cpp:327: static 
llvm::IntegerType *llvm::IntegerType::get(llvm::LLVMContext &, unsigned int): 
Assertion `NumBits >= MIN_INT_BITS && "bitwidth too small"' failed.



We are instrumenting code with EH too optimistically 

We don't report the use of compile-time "undef".
The following detects a bug at -O0 and misses it at -O1.

#include <stdio.h>

__attribute__((noinline)) bool InitializeIf(volatile bool cond, int* var) {
  if (!cond)
    return false;

  *var = 3;
  return true;
}


int main() {
  int var;
  int * volatile p = &var;
  bool initted = InitializeIf(false, &var);
  if (var == 2 || !initted)
    printf("Yep.\n");
}

Some bits of select result do not depend on select condition, and must stay 
initialized even if select condition is not. These are the bits that are equal 
and initialized in both left and right select arguments.

We hit this issue here:
https://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/arm64/simu
lator-arm64.cc?spec=svn20227&r=20213#2112

"topbits" has a bunch of zeroes in lower bits, but we mark the entire result as 
uninitialized.

1. Download Source
2. Open /msandr/README.txt, Follow the instructions.
3. Running:
  LD_USE_LOAD_BIAS=1 ./dr/exports/bin64/drrun -c ./build/libmsandr.so -- test

Error Message:
WARNING: cannot find 
/home/xx/google/memory-sanitizer/msandr/./dr/exports/bin64/../lib32/debug/libdrp
reload.so: is this an incomplete installation?
WARNING: cannot find 
/home/xx/google/memory-sanitizer/msandr/./dr/exports/bin64/../lib32/debug/libdyn
amorio.so: is this an incomplete installation?
WARNING: cannot find 
/home/xx/google/memory-sanitizer/msandr/./dr/exports/bin64/../lib32/release/libd
rpreload.so: is this an incomplete installation?
WARNING: cannot find 
/home/xx/google/memory-sanitizer/msandr/./dr/exports/bin64/../lib32/release/libd
ynamorio.so: is this an incomplete installation?
WARNING: cannot find 
/home/xx/google/memory-sanitizer/msandr/./dr/exports/bin64/../lib64/debug/libdrp
reload.so: is this an incomplete installation?
WARNING: cannot find 
/home/xx/google/memory-sanitizer/msandr/./dr/exports/bin64/../lib64/debug/libdyn
amorio.so: is this an incomplete installation?
WARNING: /home/xx/google/memory-sanitizer/msandr/./dr/exports/bin64/.. does not 
appear to be a valid DynamoRIO root
Couldn't find `__msan_get_retval_tls_offset` in /usr/bin/test
Check failed: `__msan_get_retval_tls_offset`


OS:Ubuntu 11.10 64-bit

Is there something wrong?

sorry for spam, testing e-mail notifications. 

The following code,

void f(int* p, int x) {
  *p = x;
}

with -O2 -mllvm -msan-store-clean-origin=0 -mllvm -msan-track-origins=1 -mllvm 
-msan-check-access-address=0 is compiled into

_Z1fPii():
   0:   48 b8 ff ff ff ff ff    mov    $0xffffbfffffffffff,%rax
   7:   bf ff ff 
   a:   48 21 f8                and    %rdi,%rax
   d:   48 8b 0d 00 00 00 00    mov    0x0(%rip),%rcx        # 14 <_Z1fPii+0x14>
            10: R_X86_64_GOTTPOFF   __msan_param_origin_tls-0x4
  14:   64 8b 49 08             mov    %fs:0x8(%rcx),%ecx
  18:   48 8b 15 00 00 00 00    mov    0x0(%rip),%rdx        # 1f <_Z1fPii+0x1f>
            1b: R_X86_64_GOTTPOFF   __msan_param_tls-0x4
  1f:   64 8b 52 08             mov    %fs:0x8(%rdx),%edx
  23:   89 10                   mov    %edx,(%rax)
  25:   85 d2                   test   %edx,%edx
  27:   74 13                   je     3c <_Z1fPii+0x3c>
  29:   48 ba 00 00 00 00 00    mov    $0x200000000000,%rdx
  30:   20 00 00 
  33:   48 01 d0                add    %rdx,%rax
  36:   48 83 e0 fc             and    $0xfffffffffffffffc,%rax
  3a:   89 08                   mov    %ecx,(%rax)
  3c:   89 37                   mov    %esi,(%rdi)
  3e:   c3                      retq   


Looks like the load from origin tls could be moved below the branch at offset 
27, but it's not, because it may be aliasing the store of the shadow value at 
offset 23.

Does it sound right? Could we use TBAA to tell LLVM that these are different 
memory locations?

Currently MSan uses custom printf interceptors instead of common stuff from 
sanitizer_common_interceptors.inc. We need to fix this once common printf 
interception machinery gets mature enough.

Parts of the binary may be built with different track_origins and keep_going 
settings. Current implementation will keep a random value for them in that case 
(due to odr-something linkage).

These values should be passed to __msan_init instead, which could make an 
informed decision (i.e. err on the side of track_origins=1, keep_going=1).

Because of the way we handle param tls in msan (saving it into a local at the 
function entry to deal with nested calls), interface functions dealing with 
param tls are useless - calling them overrides the same slot they work with.

Remove them from the public interface. Or reimplement as intrinsics.

Will guarantee correct origin values.
Never seen a problem with that, so maybe this is not worth the extra stack 
space.

https://code.google.com/p/chromium/issues/detail?id=338382
This chromium bug mentions a report in S32A_Opaque_BlitRow32_SSE2 with wrong 
line number in the top frame.

Please make a reduced test case out of it.

Add a clang option for track-origins

For stack buffer overflows AddressSanitizer prints a line that looks like a 
stack frame, including source file/line.

We want the same in MSan.

calling it "heap allocation" confuses users

msandr reports uninit error on content_browsertests 
WebRtcAecDumpBrowserTest.CallWithAecDump

[369/470] WebUIResourceBrowserTest.MediaInternals_Manager (6599 ms)
Note: Google Test filter = WebRtcAecDumpBrowserTest.CallWithAecDump
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from WebRtcAecDumpBrowserTest, where TypeParam =
[ RUN      ] WebRtcAecDumpBrowserTest.CallWithAecDump
[22100:22116:0130/123557:1826453235601:WARNING:proxy_service.cc(901)] PAC 
support disabled because there is no system implementation
[22124:22124:0130/123559:1826454839247:ERROR:renderer_main.cc(223)] Running 
without renderer sandbox
[22100:22100:0130/123600:1826456386156:INFO:CONSOLE(40)] "Looking at video in 
element remote-view-1", source: 
http://127.0.0.1:43889/media/webrtc_test_utilities.js (40)
[22100:22100:0130/123601:1826456450902:INFO:CONSOLE(40)] "Looking at video in 
element remote-view-2", source: 
http://127.0.0.1:43889/media/webrtc_test_utilities.js (40)
[22100:22100:0130/123601:1826456549532:INFO:CONSOLE(644)] "Negotiating 
call...", source: http://127.0.0.1:43889/media/peerconnection-call.html (644)
[22124:22132:0130/123601:1826456566139:ERROR:webrtc_video_sink_adapter.cc(45)] 
Not implemented reached in virtual void 
content::WebRtcVideoSinkAdapter::SetSize(int, int)
[22100:22100:0130/123603:1826459264608:INFO:CONSOLE(667)] "Receiving offer...", 
source: http://127.0.0.1:43889/media/peerconnection-call.html (667)
[22100:22100:0130/123604:1826459510606:INFO:CONSOLE(768)] "Receiving remote 
stream...", source: http://127.0.0.1:43889/media/peerconnection-call.html (768)
[22100:22100:0130/123604:1826459614830:INFO:CONSOLE(741)] "Receiving 
answer...", source: http://127.0.0.1:43889/media/peerconnection-call.html (741)
[22100:22100:0130/123604:1826459925922:INFO:CONSOLE(768)] "Receiving remote 
stream...", source: http://127.0.0.1:43889/media/peerconnection-call.html (768)
WARNING: no real random source present!
==22124== WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f6d01e27db8 in vp8_pick_intra_mode /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../third_party/libvpx/source/libvpx/vp8/encoder/pickinter.c:1277
    #1 0x7f6d01e71f80 in vp8cx_encode_intra_macroblock /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../third_party/libvpx/source/libvpx/vp8/encoder/encodeframe.c:1172
    #2 0x7f6d01e70095 in encode_mb_row /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../third_party/libvpx/source/libvpx/vp8/encoder/encodeframe.c:502
    ...

  Uninitialized value was created by an allocation of 'sum0' in the stack frame of function 'vp8_variance16x16_wmt'
    #0 0x7f6cf78904c0 in vp8_variance16x16_wmt /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../third_party/libvpx/source/libvpx/vp8/common/x86/variance_sse2.c:180

It seems a false positive due to msan cannot handle inline asm code:
unsigned int vp8_variance16x16_wmt(...)
{
    unsigned int sse0;
    int sum0;
    vp8_get16x16var_sse2(src_ptr, source_stride, ref_ptr, recon_stride, &sse0, &sum0) ;
    ...
}

vp8_get16x16var_sse2 is implemented as a asm routine in 
third_party/libvpx/source/libvpx/vp8/common/x86/variance_impl_sse2.asm, in 
which sum is initialized.

struct S {
  volatile unsigned x : 1;
} s;

void g() {
  s.x = 0;
}

compiles to:

%bf.load = load volatile i8* getelementptr inbounds (%struct.S* @s, i64 0, i32 
0), align 4
%bf.clear = and i8 %bf.load, -2
store volatile i8 %bf.clear, i8* getelementptr inbounds (%struct.S* @s, i64 0, 
i32 0), align 4

Sounds like we must allow volatile stores of uninitialized values. No way 
around it.

Tests could be rewritten to replace volatile assignments with either direct 
runtime calls, or something involving a branch instruction.

1. Run 100000 threads where each thread does at least one malloc/free
2. observe that memory is leaking. 

Build this test app:

#include<map>

int main(int argc, char **argv) {
  std::map<int, int> m;
  m[1] = 1;
  return 0;
}

I used this command on Ubuntu 13/10 with Clang trunk:

clang++ -g -fsanitize=memory clangstrtest.cpp -o clangstrtest

Changing optimization level (-O0, -O1, -O2) has no effect on the behaviour.

The output when run is this:

==13342== WARNING: MemorySanitizer: use-of-uninitialized-value
==13342==WARNING: Trying to symbolize code, but external symbolizer is not 
initialized!
    #0 0x7fcdba1e6a0c in std::_Rb_tree<int, std::pair<int const, int>, std::_Select1st<std::pair<int const, int> >, std::less<int>, std::allocator<std::pair<int const, int> > >::_M_erase(std::_Rb_tree_node<std::pair<int const, int> >*) stl_tree.h:1123
    #1 0x7fcdba1e6a9d in std::_Rb_tree<int, std::pair<int const, int>, std::_Select1st<std::pair<int const, int> >, std::less<int>, std::allocator<std::pair<int const, int> > >::_M_erase(std::_Rb_tree_node<std::pair<int const, int> >*) stl_tree.h:1125
    #2 0x7fcdba1e6816 in ~_Rb_tree stl_tree.h:671
    #3 0x7fcdba1e13fd in ~map stl_map.h:96
    #4 0x7fcdba1e0deb in main clangstrtest.cpp:6
    #5 0x7fcdb8d6dde4 in __libc_start_main libc-start.c:260
    #6 0x7fcdba1e0ae7 in _start ??:?

SUMMARY: MemorySanitizer: use-of-uninitialized-value ??:0 ??

This makes all binaries that use std::map uninspectable.

StoreInst stores origin unconditionally. This is wrong, because a short store 
of fully initialized value will reset origin for the entire 4-byte location.

StoreInst only stores origin for the first 4 bytes of the destination.

InsertElementInst cleans result shadow. It should Select one, instead.

Could be useful

Use "Dr. Syscall" framework to handle all known syscalls at once.

#include <string.h>

int main() {
  const char *s = "ab";
  char buf[4];
  strcpy(buf, s);
  return buf[3];
}

WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f5063578e3f in main /code/llvm/1.cc:7
    #1 0x7f506212376c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226
    #2 0x7f5063578bc0 in _start (/code/llvm/1+0x56bc0)
SUMMARY: MemorySanitizer: use-of-uninitialized-value /code/llvm/1.cc:7 main
  ORIGIN: invalid (0). Might be a bug in MemorySanitizer, please report to MemorySanitizer developers.

This is caused by __msan_copy_origin widening the address range to the nearest 
4-byte aligned addresses both on the left and on the right. If the target 
buffer is uninitialized and the source is fully initialized, this will result 
in overriding valid origin of target buffer with stale (possibly 0) origin of 
the source buffer.

Sounds like we need to do the widening only if the corresponding shadow value 
is not 0.

MSan: origins vs no-origins
ASan: multiple ABIs regarding shadow placement

Error coming from mismatching ABIs are completely not user-debuggable.
We need to enforce (in runtime, if needed) that all instrumented code in the 
process follows the same ABI.

scanf interceptor does not handle certain %specs

Here is a sample program:

#include<string>
#include<cstring>

int main(int argc, char **argv) {
  std::string a;
  a = "abc";
  strlen(a.c_str());
  return 0;
}

compile it with this exact command:

clang++ -std=c++11 -fsanitize=memory -g -O0 -fno-omit-frame-pointer 
clangstrtest.cpp -o clangstrtest

When run, I get this (on Ubuntu 13/10 amd64):

UMR in __interceptor_strlen at offset 3 inside [0x60400000eff8, +4) 

This issue is _not_ reported if you use any kind of optimization, even -O1.

Using latest clang trunk as of yesterday.

Running MSan binaries with 'make' forces reexec, which limits argv to 100 (see 
code in sanitizer::ReExec).


Breakpoint 1, ReadNullSepFileToArray (arr=<synthetic pointer>, path=<optimized 
out>, arr_size=<optimized out>) at 
../projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:249
249      CHECK_LE(count, arr_size - 1);  // FIXME: make this more flexible.
(gdb) bt
#0  ReadNullSepFileToArray (arr=<synthetic pointer>, path=<optimized out>, 
arr_size=<optimized out>) at 
../projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:249
#1  __sanitizer::ReExec () at 
../projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:259
#2  0x00002aef7ca7eaf3 in __msan_init () at 
../projects/compiler-rt/lib/msan/msan.cc:231
#3  0x00002aef7ca83f39 in __interceptor_getrlimit (resource=<optimized out>, 
rlim=0x7fffff057a90) at 
../projects/compiler-rt/lib/msan/msan_interceptors.cc:562
#4  0x00002aef7e0c7ac5 in __pthread_initialize_minimal_internal () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#5  0x00002aef7e0c62b9 in _init () from /lib/x86_64-linux-gnu/libpthread.so.0

This is not just msan issue.

.

.

Even simple unpoisoning of immediate output values ("=" constraints) will help 
with common uses of assembly (ex. cpuid).

.

MSan poisons deallocated memory with 0xffffffff origin.

Options:
1. do not poison deallocated memory
2. get a stack trace and build a proper origin label
3. use a magic origin value, common for all deallocations

[1113/2879] ExtensionWebRequestApiTest.WebRequestNewTab (TIMED OUT)
Note: Google Test filter = ExtensionWebRequestApiTest.WebRequestDeclarative1
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from ExtensionWebRequestApiTest, where TypeParam =
[ RUN      ] ExtensionWebRequestApiTest.WebRequestDeclarative1
[32040:32040:0130/182134:ERROR:renderer_main.cc(223)] Running without renderer 
sandbox
[32053:32053:0130/182136:ERROR:renderer_main.cc(223)] Running without renderer 
sandbox
[32065:32065:0130/182139:ERROR:renderer_main.cc(223)] Running without renderer 
sandbox
[32004:32004:0130/182144:1847199936639:INFO:CONSOLE(0)] "[SUCCESS] 
testCancelRequest", source: 
chrome-extension://cihikicnoeajpiaaomilgffcljicgikb/test_declarative1.html (0)
Still waiting for the following processes to finish:
        ../src/out/Release/browser_tests --allow-file-access --gtest_also_run_disabled_tests --gtest_filter=ExtensionWebRequestApiTest.WebRequestDeclarative1 --no-sandbox --single_process --user-data-dir=/tmp/.org.chromium.Chromium.qvc4\
3v/dcblOJI
[32004:32004:0130/182147:1847202774327:INFO:CONSOLE(0)] "[SUCCESS] 
testPostponeCancelRequest", source: 
chrome-extension://cihikicnoeajpiaaomilgffcljicgikb/test_declarative1.html (0)
[32004:32051:0130/182149:1847204476259:WARNING:embedded_test_server.cc(231)] 
Request not handled. Returning 404: /favicon.ico
[32004:32004:0130/182149:1847205374399:INFO:CONSOLE(0)] "[SUCCESS] 
testThirdParty", source: 
chrome-extension://cihikicnoeajpiaaomilgffcljicgikb/test_declarative1.html (0)
[32004:32004:0130/182152:1847207878894:INFO:CONSOLE(0)] "[SUCCESS] 
testFirstParty", source: 
chrome-extension://cihikicnoeajpiaaomilgffcljicgikb/test_declarative1.html (0)
[32004:32004:0130/182154:1847209751428:INFO:CONSOLE(0)] "[SUCCESS] 
testFirstPartyForCookiesUrl", source: 
chrome-extension://cihikicnoeajpiaaomilgffcljicgikb/test_declarative1.html (0)
[32004:32004:0130/182155:1847210704445:INFO:CONSOLE(0)] "[SUCCESS] 
testRedirectRequest", source: 
chrome-extension://cihikicnoeajpiaaomilgffcljicgikb/test_declarative1.html (0)
[32004:32004:0130/182156:1847211925641:INFO:CONSOLE(0)] "[SUCCESS] 
testRedirectRequest2", source: 
chrome-extension://cihikicnoeajpiaaomilgffcljicgikb/test_declarative1.html (0)
[32004:32004:0130/182157:1847212889350:INFO:CONSOLE(0)] "[SUCCESS] 
testRedirectByRegEx", source: 
chrome-extension://cihikicnoeajpiaaomilgffcljicgikb/test_declarative1.html (0)
==32004== WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7ff2110336d3 in url_matcher::URLMatcherFactory::CreateURLMatcherCondition(url_matcher::URLMatcherConditionFactory*, std::string const&, base::Value const*, std::string*) /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.\
git/src/out/Release/../../components/url_matcher/url_matcher_factory.cc:207
    #1 0x7ff211031250 in url_matcher::URLMatcherFactory::CreateFromURLFilterDictionary(url_matcher::URLMatcherConditionFactory*, base::DictionaryValue const*, int, std::string*) /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.g\
it/src/out/Release/../../components/url_matcher/url_matcher_factory.cc:121
    #2 0x7ff2131adc15 in extensions::WebRequestCondition::Create(extensions::Extension const*, url_matcher::URLMatcherConditionFactory*, base::Value const&, std::string*) /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/\
out/Release/../../chrome/browser/extensions/api/declarative_webrequest/webreques
t_condition.cc:170
    ...

    Uninitialized value was created by an allocation of 'regex' in the stack frame of function 'url_matcher::URLMatcherFactory::CreateURLMatcherCondition(url_matcher::URLMatcherConditionFactory*, std::string const&, base::Value const*, st\
d::string*)'
    #0 0x7ff211032430 in url_matcher::URLMatcherFactory::CreateURLMatcherCondition(url_matcher::URLMatcherConditionFactory*, std::string const&, base::Value const*, std::string*) /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.\
git/src/out/Release/../../components/url_matcher/url_matcher_factory.cc:186

components/url_matcher/url_matcher_factory.cc
URLMatcherCondition URLMatcherFactory::CreateURLMatcherCondition(...)
{
    ...
    re2::RE2 regex(str_value);
    if (!regex.ok()) {
    ...
}

re2.h
bool ok() const { return error_code() == NoError; }
ErrorCode error_code() const { return error_code_; }

re2.cc
RE2::RE2(const string& pattern) {
  Init(pattern, DefaultOptions);
}

The code at third_party/re2/re2/re2.cc set error_code_ proply by 
RE2::Init(const StringPiece& pattern, const Options& options)
However, it seems that msan does not instrument the code there to update the 
corresponding shadow memory

Repro:

$ cat sse.cc 
#include <emmintrin.h>

int main() {
  __m128i d;
  __m128i dst_pixel = _mm_load_si128(&d);
  _mm_srli_epi16(dst_pixel, 8);
  return 0;
}
$ clang++ sse.cc -fsanitize=memory
$ ./a.out 
==10545== WARNING: MemorySanitizer: use-of-uninitialized-value
...

16:28|zhaoqin@zhaoqin01:~/Workspace/Chrome/chromium.git/tests
> time ~/Workspace/LLVM/dr/exports/bin64/drrun   -msgbox_mask  0x0  
-no_vm_base_near_app -no_private_loader -no_mangle_app_seg -native_exec_list 
content_shell\;libfreetype.so.6\;libffmpegsumo.so\;libTestNetscapePlugIn.so\;lib
osmesa.so -native_exec_retakeover -native_exec_opt -disable_traces -c 
/usr/local/google/home/zhaoqin/Workspace/LLVM/llvm/build/lib/clang/3.5/lib/linux
/libclang_rt.msandr-x86_64.so -- 
../src/out/Release.msandr.02.03.2014/content_shell --no-sandbox 
--dump-render-tree ./CF/fuzz-2.html 
WARNING: cannot find 
/home/zhaoqin/Workspace/LLVM/dr/exports/bin64/../lib32/debug/libdrpreload.so: 
is this an incomplete installation?
WARNING: cannot find 
/home/zhaoqin/Workspace/LLVM/dr/exports/bin64/../lib32/debug/libdynamorio.so: 
is this an incomplete installation?
WARNING: cannot find 
/home/zhaoqin/Workspace/LLVM/dr/exports/bin64/../lib32/release/libdrpreload.so: 
is this an incomplete installation?
WARNING: cannot find 
/home/zhaoqin/Workspace/LLVM/dr/exports/bin64/../lib32/release/libdynamorio.so: 
is this an incomplete installation?
WARNING: /home/zhaoqin/Workspace/LLVM/dr/exports/bin64/.. does not appear to be 
a valid DynamoRIO root
#READY
[21868:21868:0203/162915:21445036688:ERROR:renderer_main.cc(223)] Running 
without renderer sandbox
CONSOLE ERROR: line 8030: Error: Invalid value for <svg> attribute width="red"
CONSOLE ERROR: line 8031: Error: Invalid value for <feSpotLight> attribute 
z="text"
CONSOLE ERROR: line 8031: Error: Invalid value for <feSpotLight> attribute 
specularExponent="text"
==21868== WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f20f70e51b3 in address /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../third_party/WebKit/Source/heap/Heap.h:512
    #1 0x7f20f70e51b3 in WebCore::HeapContainsCache::lookup(unsigned char*, WebCore::BaseHeapPage**) /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../third_party/WebKit/Source/heap/Heap.cpp:1100
    #2 0x7f20f70eb0a0 in heapPageFromAddress /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../third_party/WebKit/Source/heap/ThreadState.cpp:454
    #3 0x7f20f70eb0a0 in WebCore::ThreadState::checkAndMarkPointer(WebCore::Visitor*, unsigned char*) /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../third_party/WebKit/Source/heap/ThreadState.cpp:338
    #4 0x7f20f70e5aa6 in WebCore::Heap::checkAndMarkPointer(WebCore::Visitor*, unsigned char*) /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../third_party/WebKit/Source/heap/Heap.cpp:1274
    #5 0x7f20f70eac1b in visitStack /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../third_party/WebKit/Source/heap/ThreadState.cpp:315
    #6 0x7f20f70eac1b in WebCore::ThreadState::trace(WebCore::Visitor*) /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../third_party/WebKit/Source/heap/ThreadState.cpp:332
    #7 0x7f20f70ea92e in WebCore::ThreadState::visitRoots(WebCore::Visitor*) /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../third_party/WebKit/Source/heap/ThreadState.cpp:307
    #8 0x7f20f70e0012 in WebCore::Heap::collectGarbage(WebCore::ThreadState::StackState, WebCore::Heap::GCType) /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../third_party/WebKit/Source/heap/Heap.cpp:1324
    #9 0x7f20fc8fa4d0 in WebCore::V8GCController::gcEpilogue(v8::GCType, v8::GCCallbackFlags) /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../third_party/WebKit/Source/bindings/v8/V8GCController.cpp:380
    #10 0x7f20f7aa2fc3 in CallGCEpilogueCallbacks /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../v8/src/heap.cc:1210
    #11 0x7f20f7aa2fc3 in v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::internal::GCTracer*, v8::GCCallbackFlags) /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../v8/src/heap.cc:1172
    #12 0x7f20f7a9f9ec in v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollector, char const*, char const*, v8::GCCallbackFlags) /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../v8/src/heap.cc:813
    #13 0x7f20f7a9ee9d in CollectGarbage /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../v8/src/heap-inl.h:552
    #14 0x7f20f7a9ee9d in v8::internal::Heap::CollectAllGarbage(int, char const*, v8::GCCallbackFlags) /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../v8/src/heap.cc:714
    #15 0x7f20f766cdd4 in v8::Isolate::RequestGarbageCollectionForTesting(v8::Isolate::GarbageCollectionType) /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../v8/src/api.cc:6384
    #16 0x7f20f78ac960 in v8::internal::GCExtension::GC(v8::FunctionCallbackInfo<v8::Value> const&) /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../v8/src/extensions/gc-extension.cc:43
    #17 0x7f20f88396dc in v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../v8/src/arguments.cc:56
    #18 0x7f20f771f907 in HandleApiCallHelper<false> /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../v8/src/builtins.cc:1215
    #19 0x7f20f771f907 in Builtin_implHandleApiCall /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../v8/src/builtins.cc:1232
    #20 0x7f20f771f907 in v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../v8/src/builtins.cc:1231

  Uninitialized value was created by an allocation of 'temp.lvalue' in the stack frame of function 'base::debug::TraceLog::GetCategoryGroupEnabled(char const*)'
    #0 0x7f20f4453b20 in base::debug::TraceLog::GetCategoryGroupEnabled(char const*) /usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../../base/debug/trace_event_impl.cc:1182

SUMMARY: MemorySanitizer: use-of-uninitialized-value 
/usr/local/google/home/zhaoqin/Workspace/Chrome/chromium.git/src/out/Release/../
../third_party/WebKit/Source/heap/Heap.h:512 address
Exiting
#CRASHED - renderer (pid 21868)
Content-Type: text/plain
#CRASHED - renderer (pid 21868)
#EOF
#EOF
#EOF

real    0m23.654s
user    0m5.850s
sys 0m0.440s

The actual uninit happens at third_party/WebKit/Source/heap/ThreadState.cpp:315

NO_SANITIZE_ADDRESS
void ThreadState::visitStack(Visitor* visitor)
{
    Address* end = reinterpret_cast<Address*>(m_startOfStack);
    for (Address* current = reinterpret_cast<Address*>(m_endOfStack); current < end; ++current) {
        Heap::checkAndMarkPointer(visitor, *current);
    }
    ...
}

When visiting stack, the *current could be uninitialized. However, the error is 
reported much later when significant use happens.

(gdb) bt 8
#0  __msan_warning_noreturn () at 
/usr/local/google/home/zhaoqin/Workspace/LLVM/llvm/projects/compiler-rt/lib/msan
/msan.cc:253
#1  0x00007f1a181721b4 in address () at 
../../third_party/WebKit/Source/heap/Heap.h:512
#2  lookup () at ../../third_party/WebKit/Source/heap/Heap.cpp:1100
#3  0x00007f1a181780a1 in heapPageFromAddress () at 
../../third_party/WebKit/Source/heap/ThreadState.cpp:454
#4  checkAndMarkPointer () at 
../../third_party/WebKit/Source/heap/ThreadState.cpp:338
#5  0x00007f1a18172aa7 in checkAndMarkPointer () at 
../../third_party/WebKit/Source/heap/Heap.cpp:1274
#6  0x00007f1a18177c1c in visitStack () at 
../../third_party/WebKit/Source/heap/ThreadState.cpp:315
#7  trace () at ../../third_party/WebKit/Source/heap/ThreadState.cpp:332

at third_party/WebKit/Source/heap/Heap.cpp:1100
bool HeapContainsCache::lookup(Address address, BaseHeapPage** page)
{
    ASSERT(page);
    size_t index = hash(address);
    ASSERT(!(index & 1));
    Address cachePage = roundToBlinkPageStart(address);
    if (m_entries[index].address() == cachePage) {

The line number report is a bit off, it is the index is uninitialized because 
address is not initialized.
It looks like that the uninit is unavoidable and should be suppressed.

It calls __strtol_internal instead.

We can replace some or all (configurable) shadow checks with OR'ed stores to a 
local temp, then add a check for this temp's value at all exits from the 
function.

This will make reports much less precise, but may significantly improve 
performance.

V8 fails to start its profiling thread because pthread_create() fails with 
EINVAL (22) on the large stack size.

I think glibc hits this path:
      /* If the user also specified the size of the stack make sure it
     is large enough.  */
      if (attr->stacksize != 0
      && attr->stacksize < (__static_tls_size + MINIMAL_REST_STACK))
    return EINVAL;

msan has lots and lots of THREADLOCAL data (360 KB?), but not all of it's 
static, and most of it is the allocator cache.  It's not clear to me what's 
static vs. what's not.

We may want to minimize that to play nicely with apps that launch threads with 
small stacks.  It's not unreasonable for a profiling thread to have a small 
stack.

In particular, va_arg TLS shadow may be overwritten by instrumented call in a 
signal handler.
There are also TLS slots in certain interceptors (like glob or scandir), but 
they are unlikely to cause trouble.

Currently MSan reports the same origin for all members of dynamically allocated 
objects (pointing to the new() call for that object).
It would be nice to include the actual member name in MSan report.
Looks like we need Clang support for this - llvm IR does not have enough info 
(there are class layouts, but no member names).