Hybrid tools need to be able to identify compiler instrumented code

[ramosian-glider]

Originally reported on Google Code with ID 80

I updated browser_tests and tried running with dr_asan, and got a crash.  Ultimately
it was because we were trying to compute and access the shadow memory for a shadow
access.  Is that supposed to work?  Is the shadow reservation big enough for that?
 I guess libppGoogleNaClPluginChrome.so is now compiled by asan, or maybe this change
was introduced because I added third_party/asan to my .gclient.

For now I can easily exclude libppGoogleNaClPluginChrome.so from the hybrid instrumentation,
but long term it would be nice to have some kind of marker on the module level.  Finer
grained would be better, so we can instrument statically linked non-asan code, but
that's a separate issue.

Last bits of the log that show the asan instrumented code before and after hybrid instrumentation:

============================================================
Executing from new module: /usr/local/google/home/rnk/chromium/src/out_asan/Release/libppGoogleNaClPluginChrome.so
BB to be instrumented: 0x00007f84ff2cf100 [from /usr/local/google/home/rnk/chromium/src/out_asan/Release/libppGoogleNaClPluginChrome.so];
translating = true
 #0 0x00007f84ff2cf100 (/usr/local/google/home/rnk/chromium/src/out_asan/Release/libppGoogleNaClPluginChrome.so+0x000000000008b100)
TAG  0x00007f84ff2cf100
 +0    L3                      55                   push   %rbp %rsp -> %rsp 0xfffffff8(%rsp)

 +1    L3                      48 89 e5             mov    %rsp -> %rbp 
 +4    L3                      48 89 f8             mov    %rdi -> %rax 
 +7    L3                      48 c1 e8 03          shr    $0x0000000000000003 %rax
-> %rax 
 +11   L3                      48 b9 00 00 00 00 00 mov    $0x0000100000000000 -> %rcx

                                10 00 00
 +21   L3                      48 09 c8             or     %rcx %rax -> %rax 
 +24   L3                      80 38 00             cmp    (%rax) $0x00 
 +27   L3                      0f 85 fc 01 00 00    jnz    $0x00007f84ff2cf31d 
END 0x00007f84ff2cf100

+24 -> to be instrumented! [opcode=14, flags = 0x0008F800]

Finished instrumenting dynamorio_basic_block(PC=0x00007f84ff2cf100)
TAG  0x00007f84ff2cf100
 +0    L3                      55                   push   %rbp %rsp -> %rsp 0xfffffff8(%rsp)

 +1    L3                      48 89 e5             mov    %rsp -> %rbp 
 +4    L3                      48 89 f8             mov    %rdi -> %rax 
 +7    L3                      48 c1 e8 03          shr    $0x0000000000000003 %rax
-> %rax 
 +11   L3                      48 b9 00 00 00 00 00 mov    $0x0000100000000000 -> %rcx

                                10 00 00
 +21   L3                      48 09 c8             or     %rcx %rax -> %rax 
 +24   m4 @0x00000000735dc658  65 48 a3 18 00 00 00 mov    %rax -> %gs:0x18 
                               00 00 00 00
 +35   m4 @0x00000000735ac9d8  65 48 89 0c 25 10 00 mov    %rcx -> %gs:0x10 
                               00 00
 +44   m4 @0x00000000735d2518  48 c1 e8 03          shr    $0x0000000000000003 %rax
-> %rax 
 +48   m4 @0x00000000735dd1d8  48 b9 00 00 00 00 00 mov    $0x0000100000000000 -> %rcx

                               10 00 00
 +58   m4 @0x00000000735dc7a8  48 0b c8             or     %rax %rcx -> %rcx 
 +61   m4 @0x00000000735d8f10  80 39 00             cmp    (%rcx) $0x00 
 +64   m4 @0x00000000735d0058  74 fe                jz     @0x0000000073a91850 
 +66   m4 @0x00000000735d8c78  48 8b 01             mov    (%rcx) -> %rax 
 +69   m4 @0x00000000735d4088  8a c8                mov    %al -> %cl 
 +71   m4 @0x0000000073aa7b98  65 48 a1 18 00 00 00 mov    %gs:0x18 -> %rax 
                               00 00 00 00
 +82   m4 @0x00000000735d57b0  48 83 e0 07          and    $0x0000000000000007 %rax
-> %rax 
 +86   m4 @0x00000000735d7078  3a c1                cmp    %al %cl 
 +88   m4 @0x00000000735d3380  7c fe                jl     @0x0000000073a91850 
 +90   m4 @0x0000000073aa9a18  65 48 a1 18 00 00 00 mov    %gs:0x18 -> %rax 
                               00 00 00 00
 +101  m4 @0x00000000735db838  48 8b f8             mov    %rax -> %rdi 
 +104  m4 @0x00000000735d2e00  e8 4b ef 98 96       call   $0x0000000009f5c680 %rsp
-> %rsp 0xfffffff8(%rsp) 
 +109  m4 @0x0000000073a91850                       <label>
 +109  m4 @0x00000000735dd4a8  65 48 a1 18 00 00 00 mov    %gs:0x18 -> %rax 
                               00 00 00 00
 +120  m4 @0x00000000735d9438  65 48 8b 0c 25 10 00 mov    %gs:0x10 -> %rcx 
                               00 00
 +129  L3                      80 38 00             cmp    (%rax) $0x00 
 +132  L3                      0f 85 fc 01 00 00    jnz    $0x00007f84ff2cf31d 
END 0x00007f84ff2cf100

Reported by rnk@google.com on 2012-06-19 18:03:51

[ramosian-glider]

Chatted with Alexander, and decided to look for an __asan_init import.

Reported by rnk@google.com on 2012-06-19 18:18:12

[ramosian-glider]

>> we were trying to compute and access the shadow memory for a shadow access.
This will hit an mprotect-ed memory region

Reported by konstantin.s.serebryany on 2012-06-20 06:06:45

[ramosian-glider]

Just to clarify in this thread (compared to chat messages scattered here and there)

Shadow of a shadow is a mprotect'ed region by design, as the instrumented app should
never be allowed to access shadow (e.g. by mistake).

> long term it would be nice to have some kind of marker on the module level.
> Finer grained would be better, so we can instrument statically linked
> non-asan code, but that's a separate issue.
I remember you were suggesting to put the instrumented code into a special section
and never instrument this give section. Or the other way around.

Reported by timurrrr@google.com on 2012-07-19 10:22:50

[ramosian-glider]

Yeah, a special section makes sense if we want to support mixing instrumented and non-instrumented
code in the same module, which I expect we will on Windows.

It's hard because we have to figure it out at least twice for Linux and Windows.

Reported by rnk@google.com on 2012-07-19 14:31:08

[ramosian-glider]

is this still relevant? 

Reported by konstantin.s.serebryany on 2013-12-26 14:45:22

[ramosian-glider]

The DRASan code still has this TODO:
https://code.google.com/p/address-sanitizer/source/browse/trunk/dynamorio/dr_asan.cpp#532

I remember adding an import iterator to DR, but I forget if I added ELF support.  Anyway,
DRASan could use that to look for __asan_init imports, like the comment says.

I don't think anyone is actively pursuing DRASan right now though, so I'll close it.

Reported by rnk@google.com on 2013-12-26 17:16:41

• Status changed: WontFix
• Labels added: FixLater

[ramosian-glider]

Adding Project:AddressSanitizer as part of GitHub migration.

Reported by ramosian.glider on 2015-07-30 09:12:59

• Labels added: ProjectAddressSanitizer