title: Modify Relocations Conditionally at Runtime
body: <p><strong>TL;DR</strong></p>
  <p>I want to <strong>overwrite</strong> <code>.got, .got.plt,...</code> to point to the <strong>correct</strong> addresses, because the linker makes <strong>wrong</strong> decisions.</p>
  <hr />
  <p>I need to use two different <em>dynamic allocation</em> functions (i.e., <code>malloc(),...</code>) in the code. The appropriate one will be selected based on some condition during program execution. Therefore, I provided two <code>glibc</code> instances and used the <code>LD_PRELOAD</code> trick. The <code>LD_PRELOAD</code> value is something like the following:</p>
  <pre><code>LD_PRELOAD=multiplexer_library.so:glibc1.so:glibc2.so
  </code></pre>
  <p>where, <code>multiplexer_library.so</code> chooses the correct library. <code>glibc1.so</code> is accessed using <code>dlsym(RTLD_NEXT, &quot;malloc&quot;)</code> and <code>glibc2.so</code> is accessed using <code>dlopen()</code> followed by <code>dlsym()</code>. The same goes for <code>calloc(),...</code></p>
  <p>The problem is that the second malloc will <strong>interfere</strong> with the first one. This happens because <strong>all</strong> dynamic relocations of the <strong>latter</strong> will be <strong>mapped</strong> to the <strong>former</strong> by the linker. For example, when <code>glibc2.so</code> calls the global function pointer <code>morecore</code> it will be mapped to the <code>morecore</code> and its target which is the <code>__default_morecore()</code> function in <code>glibc1.so</code>. The relocation entry for this global variable in <code>glibc2.so</code> is as follows:</p>
  <pre><code>0000003addc0  085600000006 R_X86_64_GLOB_DAT 00000000003af4d8 __morecore@@GLIBC_2.2.5 + 0
  </code></pre>
  <p>I traced the execution in <code>Pin</code>. <strong>125</strong> out of over <strong>1370</strong> relocation entries, were <strong>accessed</strong> in my code during dynamic allocations. For example, an <strong>imporant</strong> entry is the global variable <code>__curbrk</code> which determines the <code>brk</code> boundary for dynamic allocations (NOTE THAT I provided an <strong>isolated</strong> brk region for <strong>each</strong> library at the system call level). This will obviously <strong>corrupt</strong> the allocations, because both allocators use the same <code>__curbrk</code>. The relocation entry for <code>__curbrk</code> in <code>glibc1.so</code> is shown below:</p>
  <pre><code>0000003adeb8  044400000006 R_X86_64_GLOB_DAT 00000000003b10b8 __curbrk@@GLIBC_2.2.5 + 0
  </code></pre>
  <p>I tried to <strong>rename</strong> these conflicting names but <strong>125</strong> is a <strong>huge</strong> number and the code is <strong>hard</strong> to grasp. Because it is full of <strong>nested macros</strong> which makes the manual rename solution, practically, <strong>infeasible</strong>.</p>
  <p>IIUC, for <strong>each</strong> relocation entry, there exists <strong>a memory address</strong> (e.g., somewhere in <code>.got,...</code>) where the <strong>linker</strong> will put the <strong>target</strong> relocated address and this address is <strong>exclusive</strong> to <strong>each</strong> shared library. I will call that address the <strong>TARGET HOLDER</strong>. For example, in the <code>__curbrk</code> case, the linker placed the <em>runtime</em> address for the <code>__curbrk</code> variable of <code>glibc1.so</code> in the <strong>target holder</strong> of <code>__curbrk</code> in <strong>both</strong> <code>glibc1.so</code> and <code>glibc2.so</code>. If this is right, at <strong>runtime</strong>, I will have to <strong>update</strong> the value in the <strong>target holder</strong> of <code>__curbrk</code> in <code>glibc2.so</code> to hold the <strong>runtime</strong> address of <code>__curbrk</code> variable of <code>glibc2.so</code>. And to <strong>completely</strong> resolve the problem, this should be done for <strong>all</strong> of the <strong>125</strong> relocation entries <strong>accessed</strong> by <code>malloc(),...</code>. Is it possible?</p>
  <p>Any help is appreciated!</p>