[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141016165839.GA1257@euler>
Date: Thu, 16 Oct 2014 18:58:40 +0200
From: Felix Janda <felix.janda@...teo.de>
To: musl@...ts.openwall.com
Subject: Re: debugging problem with musl ld and qemu-ppc
Rich Felker wrote:
> On Thu, Oct 16, 2014 at 08:09:01AM +0200, Felix Janda wrote:
> > Hello list,
> >
> > can you maybe help me debugging the following problem with qemu-ppc?
> > It gives an invalid instruction error after doing:
> >
> > tar -xf crossx86-powerpc-linux-musl-0.9.9.tar.xz
> > # (I get something similar for other versions of musl or gcc)
> > cat > a.s <<EOF
> > b _GLOBAL_OFFSET_TABLE_@...al
> > EOF
> > cat > b.c <<EOF
> > int main(void) { return 0; }
> > EOF
> > ../powerpc-linux-musl/bin/powerpc-linux-musl-gcc -o good b.c
> > ../powerpc-linux-musl/bin/powerpc-linux-musl-gcc -o bad a.s b.c
> > # set up symlinks to make 'qemu-ppc good' work
> > qemu-ppc bad
> >
> > After musl ld has done its work it jumps to libgcc's _init and
> > very soon tries to execute some data.
> >
> > When executing in some chroot the 'qemu-ppc -d in_asm' for
> > good and bad is exactly the same up to two instructions in
> > libgcc until it diverges (and bad crashes).
> >
> > Do you have any ideas what could be the problem?
>
> Using the cross compiler I had lying around, I get a warning while
> linking "bad":
>
> /opt/powerpc-linux-musl/bin/../lib/gcc/powerpc-linux-musl/4.7.2/../../../../powerpc-linux-musl/bin/ld: bss-plt forced due to /tmp/ccfPiE1t.o
>
> I suspect this is happening for you too (possibly without a warning
> being printed?) and that this is the cause of the problem: something
> about your asm file is forcing the linker to use the old "bss-plt"
> dynamic linking model, which musl does not support, rather than the
> "secure-plt" model.
Thanks for reproducing the issue and explaining what is bss-plt.
Depending on the compiler I also got this warning. Sorry for forgetting
to mention this.
> The "bss-plt" model requires the dynamic linker to generate direct
> call instructions inline in a writable (mode rwx!) page rather than
> having the PLT thunks load their actual function addresses from
> pointers filled into the GOT by the dynamic linker, so it's a major
> risk from a security standpoint, and also a lot more work to implement
> in the dynamic linker. As such, when powerpc support was added we
> opted to omit this model and push for use of the more secure model
> that works like every other arch.
>
> What I'm not clear about is the cause for why the linker is forcing
> you back to the bss-plt model. It might be a matter of the strange
> relocation type you put in a.s:
>
> 00000000 <.text>:
> 0: 48 00 00 00 b 0x0
> 0: R_PPC_LOCAL24PC _GLOBAL_OFFSET_TABLE_
The problem caused a self-compiled native gcc to crash because the file
"mpn/powerpc32/elf.m4" (used to generate some assembly) in the gmp tree
contains a similar instruction.
I've found the part in binutils emitting the warning and will try to see
why it forces bss-plt.
Thanks,
Felix
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
