ELF loader rejects older glibc binary

ELF loader rejects older glibc binary

[Isaac Dunham]

Short version: I tried using a "libc6" shared binary that apparently
is compatible with glibc back to 2.1, and musl rejected it as not a valid 
dynamic program.
I've used this same binary on Debian 6, so it works elsewhere; but
musl's loader is rejecting it.

Long version:
I'm trying to use a Brother DCP7065DN network printer with Alpine Linux;
the drivers 
are closed-source though modified binaries are redistributable.
The format used is a binary format having some relationship to PCL;
I can't reverse-engineer it, so I'm stuck using the binary drivers
for now.
The drivers in question may be found here:
http://support.brother.com/g/b/downloadlist.aspx?c=us&lang=en&prod=dcp7065dn_all&os=128

I grabbed the "LPR printer driver".
After extracting it (ar x dcp7065*deb; tar xvzf data.tar.gz),
I found the binaries in 
usr/local/Brother/Printer/DCP7065DN/{inf,lpd}/;
the one I'd suggest poking at first is 
"usr/local/Brother/Printer/DCP7065DN/lpd/rawtobr3" (I previously determined
that rawtobr3 does all the conversions).
After locating the binaries and verifying with file that they were
dynamically linked ELF binaries, I ran ldd.
When this failed with the message:
ldd: rawtobr3: Not a valid dynamic program
I then ran "strace ldd rawtobr3"; the output indicates that musl mmap'd it
and failed without trying to run it:

---start strace output---
execve("/usr/bin/ldd", ["ldd", "rawtobr3"], [/* 19 vars */]) = 0
open("rawtobr3", O_RDONLY|O_LARGEFILE)  = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\324\207\4\0104\0\0\0"..., 936) = 936
mmap2(0x8048000, 49152, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x566f1000
munmap(0x566f1000, 49152)               = 0
writev(2, [{"ldd: rawtobr3: Not a valid dynam"..., 43}, {NULL, 0}], 2ldd: rawtobr3: Not a valid dynamic program
) = 43
exit_group(1)                           = ?
+++ exited with 1 +++
---end strace output---

strings suggests that it expects glibc 2.1 ABI, and that almost all the
symbol requirements are met (_IO_stdin_used being the possible exception).


Thanks,
Isaac Dunham

Re: ELF loader rejects older glibc binary

[Timo Teras]

On Wed, 25 Jun 2014 20:59:24 -0700
Isaac Dunham <ibid.ag@gmail.com> wrote:

> Long version:
> I'm trying to use a Brother DCP7065DN network printer with Alpine
> Linux; the drivers 
> are closed-source though modified binaries are redistributable.
> The format used is a binary format having some relationship to PCL;
> I can't reverse-engineer it, so I'm stuck using the binary drivers
> for now.
> The drivers in question may be found here:
> http://support.brother.com/g/b/downloadlist.aspx?c=us&lang=en&prod=dcp7065dn_all&os=128
> 
> I grabbed the "LPR printer driver".
> After extracting it (ar x dcp7065*deb; tar xvzf data.tar.gz),
> I found the binaries in 
> usr/local/Brother/Printer/DCP7065DN/{inf,lpd}/;
> the one I'd suggest poking at first is 
> "usr/local/Brother/Printer/DCP7065DN/lpd/rawtobr3" (I previously
> determined that rawtobr3 does all the conversions).
> After locating the binaries and verifying with file that they were
> dynamically linked ELF binaries, I ran ldd.
> When this failed with the message:
> ldd: rawtobr3: Not a valid dynamic program
> I then ran "strace ldd rawtobr3"; the output indicates that musl
> mmap'd it and failed without trying to run it:
> 
> ---start strace output---
> execve("/usr/bin/ldd", ["ldd", "rawtobr3"], [/* 19 vars */]) = 0
> open("rawtobr3", O_RDONLY|O_LARGEFILE)  = 3
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\324\207\4\0104\0\0\0"...,
> 936) = 936 mmap2(0x8048000, 49152, PROT_READ|PROT_EXEC, MAP_PRIVATE,
> 3, 0) = 0x566f1000 munmap(0x566f1000, 49152)               = 0
> writev(2, [{"ldd: rawtobr3: Not a valid dynam"..., 43}, {NULL, 0}],
> 2ldd: rawtobr3: Not a valid dynamic program ) = 43
> exit_group(1)                           = ? +++ exited with 1 +++
> ---end strace output---
> 
> strings suggests that it expects glibc 2.1 ABI, and that almost all
> the symbol requirements are met (_IO_stdin_used being the possible
> exception).

Do note that Alpine Linux runs grsec which includes PaX features. One
is that text relocations are disabled by default.

Try first:
  paxctl -c -pem /path/to/rawtobr3

if it makes any difference.

If it was missing symbol, you should get an error message with the
symbol name(s) that are missing.

/Timo

Re: ELF loader rejects older glibc binary

[Rich Felker]

On Wed, Jun 25, 2014 at 08:59:24PM -0700, Isaac Dunham wrote:
> Short version: I tried using a "libc6" shared binary that apparently
> is compatible with glibc back to 2.1, and musl rejected it as not a valid 
> dynamic program.
> I've used this same binary on Debian 6, so it works elsewhere; but
> musl's loader is rejecting it.
> 
> Long version:
> I'm trying to use a Brother DCP7065DN network printer with Alpine Linux;
> the drivers 
> are closed-source though modified binaries are redistributable.
> The format used is a binary format having some relationship to PCL;
> I can't reverse-engineer it, so I'm stuck using the binary drivers
> for now.
> The drivers in question may be found here:
> http://support.brother.com/g/b/downloadlist.aspx?c=us&lang=en&prod=dcp7065dn_all&os=128
> 
> I grabbed the "LPR printer driver".
> After extracting it (ar x dcp7065*deb; tar xvzf data.tar.gz),
> I found the binaries in 
> usr/local/Brother/Printer/DCP7065DN/{inf,lpd}/;
> the one I'd suggest poking at first is 
> "usr/local/Brother/Printer/DCP7065DN/lpd/rawtobr3" (I previously determined
> that rawtobr3 does all the conversions).
> After locating the binaries and verifying with file that they were
> dynamically linked ELF binaries, I ran ldd.
> When this failed with the message:
> ldd: rawtobr3: Not a valid dynamic program
> I then ran "strace ldd rawtobr3"; the output indicates that musl mmap'd it
> and failed without trying to run it:

This error means that map_library either failed to map the program
according to its program headers, or found something invalid in the
ELF or program headers that it didn't know how to process.

> ---start strace output---
> execve("/usr/bin/ldd", ["ldd", "rawtobr3"], [/* 19 vars */]) = 0
> open("rawtobr3", O_RDONLY|O_LARGEFILE)  = 3
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\324\207\4\0104\0\0\0"..., 936) = 936
> mmap2(0x8048000, 49152, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x566f1000
> munmap(0x566f1000, 49152)               = 0
> writev(2, [{"ldd: rawtobr3: Not a valid dynam"..., 43}, {NULL, 0}], 2ldd: rawtobr3: Not a valid dynamic program

As you can see, mmap was requested to map at address 0x8048000 but
instead chose 0x566f1000. I don't see why this would happen since, at
this point, ld-musl and maybe vdso should be the only mappings and the
kernel does not put them at such low addresses.

> ) = 43
> exit_group(1)                           = ?
> +++ exited with 1 +++
> ---end strace output---
> 
> strings suggests that it expects glibc 2.1 ABI, and that almost all the
> symbol requirements are met (_IO_stdin_used being the possible exception).

AFAIK the glibc 2.1 ABI does not have large files, so any function
that takes off_t is going to have ABI mismatch, I think. It should be
possible to work around this with an LD_PRELOAD library. Eventually I
hope to have an internal solution. But this has nothing to do with the
load failure so first you need to figure that out.

Rich

Re: ELF loader rejects older glibc binary

[Isaac Dunham]

As was suggested, I tried paxctl:
dcp/usr/local/Brother/Printer/DCP7065DN# paxctl -c -pem lpd/rawtobr3
file lpd/rawtobr3 had a PT_GNU_STACK program header, converted

dcp/usr/local/Brother/Printer/DCP7065DN# ldd lpd/rawtobr3
ldd: lpd/rawtobr3: Not a valid dynamic program

dcp/usr/local/Brother/Printer/DCP7065DN# strace ldd lpd/rawtobr3
execve("/usr/bin/ldd", ["ldd", "lpd/rawtobr3"], [/* 19 vars */]) = 0
open("lpd/rawtobr3", O_RDONLY|O_LARGEFILE) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\324\207\4\0104\0\0\0"..., 936) = 936
mmap2(0x8048000, 49152, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4ed25000
munmap(0x4ed25000, 49152)               = 0
writev(2, [{"ldd: lpd/rawtobr3: Not a valid d"..., 47}, {NULL, 0}], 2ldd: lpd/rawtobr3: Not a valid dynamic program
) = 47
exit_group(1)                           = ?
+++ exited with 1 +++

That's all I know.

Thanks,
Isaac Dunham

Re: ELF loader rejects older glibc binary

[Isaac Dunham]

On Thu, Jun 26, 2014 at 10:50:08AM +0300, Timo Teras wrote:
> On Wed, 25 Jun 2014 20:59:24 -0700
> Isaac Dunham <ibid.ag@gmail.com> wrote:
> > The drivers in question may be found here:
> > http://support.brother.com/g/b/downloadlist.aspx?c=us&lang=en&prod=dcp7065dn_all&os=128
> > 
> > I grabbed the "LPR printer driver".
> > After extracting it (ar x dcp7065*deb; tar xvzf data.tar.gz),
> > I found the binaries in 
> > usr/local/Brother/Printer/DCP7065DN/{inf,lpd}/;
> > the one I'd suggest poking at first is 
> > "usr/local/Brother/Printer/DCP7065DN/lpd/rawtobr3" (I previously
> > determined that rawtobr3 does all the conversions).
> > After locating the binaries and verifying with file that they were
> > dynamically linked ELF binaries, I ran ldd.
> > When this failed with the message:
> > ldd: rawtobr3: Not a valid dynamic program
> > I then ran "strace ldd rawtobr3"; the output indicates that musl
> > mmap'd it and failed without trying to run it:
> > 
> > ---start strace output---
> > execve("/usr/bin/ldd", ["ldd", "rawtobr3"], [/* 19 vars */]) = 0
> > open("rawtobr3", O_RDONLY|O_LARGEFILE)  = 3
> > read(3,
> > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\324\207\4\0104\0\0\0"...,
> > 936) = 936 mmap2(0x8048000, 49152, PROT_READ|PROT_EXEC, MAP_PRIVATE,
> > 3, 0) = 0x566f1000 munmap(0x566f1000, 49152)               = 0
> > writev(2, [{"ldd: rawtobr3: Not a valid dynam"..., 43}, {NULL, 0}],
> > 2ldd: rawtobr3: Not a valid dynamic program ) = 43
> > exit_group(1)                           = ? +++ exited with 1 +++
> > ---end strace output---
> > 
> > strings suggests that it expects glibc 2.1 ABI, and that almost all
> > the symbol requirements are met (_IO_stdin_used being the possible
> > exception).
> 
> Do note that Alpine Linux runs grsec which includes PaX features. One
> is that text relocations are disabled by default.
> 
> Try first:
>   paxctl -c -pem /path/to/rawtobr3
> 
> if it makes any difference.

Thanks for mentioning that; I've just tested on my other musl system,
and it's definitely a kernel difference (it runs on a non-pax system.)

That said, paxctl didn't make a difference.

Thanks,
Isaac Dunham

Re: ELF loader rejects older glibc binary

[Rich Felker]

On Thu, Jun 26, 2014 at 05:46:38PM -0700, Isaac Dunham wrote:
> On Thu, Jun 26, 2014 at 10:50:08AM +0300, Timo Teras wrote:
> > On Wed, 25 Jun 2014 20:59:24 -0700
> > Isaac Dunham <ibid.ag@gmail.com> wrote:
> > > The drivers in question may be found here:
> > > http://support.brother.com/g/b/downloadlist.aspx?c=us&lang=en&prod=dcp7065dn_all&os=128
> > > 
> > > I grabbed the "LPR printer driver".
> > > After extracting it (ar x dcp7065*deb; tar xvzf data.tar.gz),
> > > I found the binaries in 
> > > usr/local/Brother/Printer/DCP7065DN/{inf,lpd}/;
> > > the one I'd suggest poking at first is 
> > > "usr/local/Brother/Printer/DCP7065DN/lpd/rawtobr3" (I previously
> > > determined that rawtobr3 does all the conversions).
> > > After locating the binaries and verifying with file that they were
> > > dynamically linked ELF binaries, I ran ldd.
> > > When this failed with the message:
> > > ldd: rawtobr3: Not a valid dynamic program
> > > I then ran "strace ldd rawtobr3"; the output indicates that musl
> > > mmap'd it and failed without trying to run it:
> > > 
> > > ---start strace output---
> > > execve("/usr/bin/ldd", ["ldd", "rawtobr3"], [/* 19 vars */]) = 0
> > > open("rawtobr3", O_RDONLY|O_LARGEFILE)  = 3
> > > read(3,
> > > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\324\207\4\0104\0\0\0"...,
> > > 936) = 936 mmap2(0x8048000, 49152, PROT_READ|PROT_EXEC, MAP_PRIVATE,
> > > 3, 0) = 0x566f1000 munmap(0x566f1000, 49152)               = 0
> > > writev(2, [{"ldd: rawtobr3: Not a valid dynam"..., 43}, {NULL, 0}],
> > > 2ldd: rawtobr3: Not a valid dynamic program ) = 43
> > > exit_group(1)                           = ? +++ exited with 1 +++
> > > ---end strace output---
> > > 
> > > strings suggests that it expects glibc 2.1 ABI, and that almost all
> > > the symbol requirements are met (_IO_stdin_used being the possible
> > > exception).
> > 
> > Do note that Alpine Linux runs grsec which includes PaX features. One
> > is that text relocations are disabled by default.
> > 
> > Try first:
> >   paxctl -c -pem /path/to/rawtobr3
> > 
> > if it makes any difference.
> 
> Thanks for mentioning that; I've just tested on my other musl system,
> and it's definitely a kernel difference (it runs on a non-pax system.)

It's probably some dubious pax feature that disallows mmap at a chosen
address without MAP_FIXED. If you can just edit the binary to use
ld-musl as its PT_INTERP rather than invoking it via ld-musl manually,
the kernel will do the mapping and I think it will work fine then.

Rich