Is it part of ASR (address-space randomization)? If so, then it couldn't be used in static linking, which would explain the discrepancy.
On Jan 25, 2009, at 4:21 AM, Gabe Black wrote: > I figured out what's going on. This is a glibc security measure where > they scramble pointers people might try to maliciously tamper with. If > you change the pointer, you (supposedly) can't easily tell what you're > changing it too. The problem here is that the pointer it's > unscrambling > is just a normal pointer so it's really scrambling it. A likely reason > I've never seen this before is that this mechanism isn't used for > static > binaries for some reason. > > Gabe > > Gabe Black wrote: >> I figured part of this out (objdump is my new best friend), but I >> ran into another mystery. The problem I'm trying to diagnose is >> that the >> init process gets a segfault at some point as it comes up because it >> jumps to a totally bizarre and meaningless pc. The dynamic linker has >> finished settup up the executable, and /lib/libc.so.6 is doing >> something >> for a while. Eventually, it loads a value from memory, rotates it >> right >> by 17 bits, xors it against something it got out of TLS, and then >> jumps >> to the (totally wrong) address. I have no idea how this is supposed >> to >> do anything but break horribly, so I was wondering if anyone else has >> ever seen something like this before and knows what the heck libc is >> trying to do. I've verified that the this piece of code really does >> exist in libc (below), but unfortunately there's no debug >> information so >> I can't easily trace it to the originating C. The fact that the REX >> prefix (0x48) exists in there an unusually large number of times >> makes >> me confident this is actually code. >> >> Gabe >> >> 6a383: 48 8b 05 e6 3a 2d 00 mov >> 0x2d3ae6(%rip),%rax # 33de70 <argp_program_version_hook+0x1a0> >> 6a38a: 48 c1 c8 11 ror $0x11,%rax >> 6a38e: 64 48 33 04 25 30 00 xor %fs:0x30,%rax >> 6a395: 00 00 >> 6a397: ff d0 callq *%rax >> >> Gabe Black wrote: >> >>> Recently I've had the good fortune of discovering what a pain >>> it is >>> to try to debug user level code in FS with no symbols. I'm going to >>> think about ways to make the process easier, and I was wondering if >>> there are any tricks other people know of that might help. Also, >>> does >>> anyone know of a good way to use gdb on the dynamic linker binary? I >>> know /sbin/init is dynamically linked and I know where the linker >>> gets >>> stuck in memory, but I haven't been able to get gdb to tell me >>> anything >>> useful about it (/lib64/ld-linux-x86-64.so.2). For instance, I'd >>> like to >>> disassemble its entry point, but gdb insists it can't read it for >>> some >>> reason. The entry point according to the elf headers is 0xb10, and >>> from >>> tracing m5 it appears that that's being relocated to >>> 0x2b8ff0abfb10. I'm >>> sure I can get the bytes I need with, for instance, hexedit, but >>> that's >>> a little too masochistic I think. >>> >>> Gabe >>> _______________________________________________ >>> m5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/listinfo/m5-dev >>> >>> >> >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
