Closed Bug 628233 Opened 9 years ago Closed 9 years ago

elhack breaks Android because linker assumes there is only one read-only PT_LOAD

Categories

(Core :: General, defect)

ARM
Android
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla2.0b11

People

(Reporter: glandium, Assigned: glandium)

References

Details

Attachments

(2 files)

When enabling elfhack on Android, it looks like it unveals a bug in the dynamic linker. I'm investigating what's wrong there, and will update this bug accordingly.
OS: Linux → Android
For the record, here is what I can see with gdb:
   0x72ccb440:	ldr	r3, [pc, #48]	; 0x72ccb478
   0x72ccb444:	lsr	r1, r0, #16
   0x72ccb448:	lsr	r2, r0, #8
   0x72ccb44c:	and	r1, r1, #255	; 0xff
   0x72ccb450:	and	r2, r2, #255	; 0xff
=> 0x72ccb454:	ldrb	r12, [r3, r1]
   0x72ccb458:	ldrb	r1, [r3, r2]
   0x72ccb45c:	and	r2, r0, #255	; 0xff
   0x72ccb460:	ldrb	r2, [r3, r2]

The arrow points to where the crash is happening. r3 is 0xe4eb6a30, r1 is 0, and there's nothing mapped at the address pointed by [r3,r1].
The value in r3 comes from 0x72ccb478, which, considering the mapping, points at VMA 0xccb478 in libxul.so. That happens to be the location of the last text relocation in libxul.so:
(...)
00ccb0a8  00000017 R_ARM_RELATIVE   
00ccb308  00000017 R_ARM_RELATIVE   
00ccb478  00000017 R_ARM_RELATIVE   
00eb1e0c  00000017 R_ARM_RELATIVE   
00eb1e10  00000017 R_ARM_RELATIVE   
(...)
.text ending at VMA 0xccb47c.

Now, following execution, this is what I can observe:
When reaching the reloc_library in linker.c, after all libraries have been mapped to memory at their final location, the content of that address is (obviously), the non relocated value 0xeb6a30, which is (also obviously) what is present in the binary.
When reaching the init function of libxul.so (iow, the beginning of the elfhack injected function), which means after relocations handled by the dynamic linker and before elfhack injected code handles its own relocations, the value at that location is 0x72eb6a30, which is correct.
After the injected code has run, the value at the location is still 0x72eb6a30, which is still correct.

And unfortunately, I can't set a watchpoint to see what is modifying that afterwards :(
In fact, it appears *all* dynamic relocations are performed a second time later on.
Summary: Fix whatever elfhack breaks on Android → Android linker assumes there is only one read-only PT_LOAD
Summary: Android linker assumes there is only one read-only PT_LOAD → elhack breaks Android because linker assumes there is only one read-only PT_LOAD
Attachment #507493 - Flags: review?(khuey)
FWIW, this alone allows elfhack to work properly on current m-c. (IOW, this doesn't depend on elfhack fixes like bug 628618)
Attachment #507492 - Flags: review?(mwu) → review+
Attachment #507492 - Flags: approval2.0?
Attachment #507493 - Flags: approval2.0?
Attachment #507492 - Flags: approval2.0? → approval2.0+
Attachment #507493 - Flags: approval2.0? → approval2.0+
http://hg.mozilla.org/mozilla-central/rev/ce61c1a52114
http://hg.mozilla.org/mozilla-central/rev/4949da34f21b
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b11
Depends on: 637243
You need to log in before you can comment on or make changes to this bug.