DynamoRIO(/loader) changes the address of dynamically linked library

[Shuntian Liu]

Hi,

I am working on adding trace support for DynamoRIO on AArch64 and had the problem of DynamoRIO (or maybe the loader) changing the address of a binary file at runtime. Here is a snippet of a the objdump of the binary:

0000000000400570 <_start>:

  400570:       d280001d        mov     x29, #0x0                       // #0

  400574:       d280001e        mov     x30, #0x0                       // #0

  400578:       aa0003e5        mov     x5, x0

  40057c:       f94003e1        ldr     x1, [sp]

  400580:       910023e2        add     x2, sp, #0x8

  400584:       910003e6        mov     x6, sp

  400588:       90000000        adrp    x0, 400000 <__ehdr_start>

  40058c:       9116a000        add     x0, x0, #0x5a8

  400590:       90000003        adrp    x3, 400000 <__ehdr_start>

  400594:       9138a063        add     x3, x3, #0xe28

  400598:       90000004        adrp    x4, 400000 <__ehdr_start>

  40059c:       913bc084        add     x4, x4, #0xef0

  4005a0:       9400005a        bl      400708 <__libc_start_main>

  4005a4:       97ffff67        bl      400340 <abort>

And this is a statically linked binary file, looking at the basic blocks produced by DynamoRIO, the first block does indeed start at the address where  <_start> is (0x0000000000400570).

in dynamorio_basic_block(tag=0x0000000000400570, for_trace=0)

TAG  0x0000000000400570

 +0    L3 @0x0000fffd92535e40  d280001d   movz   $0x0000 lsl $0x00 -> %x29

 +4    L3 @0x0000fffd92535f08  d280001e   movz   $0x0000 lsl $0x00 -> %x30

 +8    L3 @0x0000fffd92535fd0  aa0003e5   orr    %xzr %x0 lsl $0x00 -> %x5

 +12   L3 @0x0000fffd92536098  f94003e1   ldr    (%sp)[8byte] -> %x1

 +16   L3 @0x0000fffd92536118  910023e2   add    %sp $0x0008 lsl $0x00 -> %x2

 +20   L3 @0x0000fffd925361e0  910003e6   add    %sp $0x0000 lsl $0x00 -> %x6

 +24   L3 @0x0000fffd925362a8  90000000   adrp   <rel> 0x0000000000400000 -> %x0

 +28   L3 @0x0000fffd92536328  9116a000   add    %x0 $0x05a8 lsl $0x00 -> %x0

 +32   L3 @0x0000fffd925363f0  90000003   adrp   <rel> 0x0000000000400000 -> %x3

 +36   L3 @0x0000fffd92536470  9138a063   add    %x3 $0x0e28 lsl $0x00 -> %x3

 +40   L3 @0x0000fffd92536538  90000004   adrp   <rel> 0x0000000000400000 -> %x4

 +44   L3 @0x0000fffd925365b8  913bc084   add    %x4 $0x0ef0 lsl $0x00 -> %x4

 +48   L3 @0x0000fffd92536680  9400005a   bl     $0x0000000000400708 -> %x30

END 0x0000000000400570

But this is not the case with dynamically linking, if I instrument a dynamically linked binary, I get something like this (the first basic block):

in dynamorio_basic_block(tag=0x0000ffff81e400c0, for_trace=0)

TAG  0x0000ffff81e400c0

 +0    L3 @0x0000fffd3deb9e40  910003e0   add    %sp $0x0000 lsl $0x00 -> %x0

 +4    L3 @0x0000fffd3deb9f08  9400029f   bl     $0x0000ffff81e40b40 -> %x30

END 0x0000ffff81e400c0

which is an entirely different address and does not appear in the objdump file of the binary at all. I am wondering if anyone knows what is going on here and if there is any way of turning this feature off so that the runtime address and the objdump addresses can stay the same (so that it is easier for debugging and see what is going on)

[Derek Bruening]

Looking back over old messages and found this one: this is simply ELF types EXEC vs DYN where the kernel assumes DYN are fully relocatable and loads them into a certain region of address space (and they often have an on-disk base of 0 and so couldn't be loaded there anyway so no this cannot be "turned off"; what can be turned off is ALSR to try to have a consistent address from run to run).