Re: [Qemu-devel] ANN: DetaolB v0.4 is released

[Rob Landley <rob@landley.net>]

On Tuesday 10 July 2007 14:30:38 Blue Swirl wrote:
> > The sparc platform has a problem that if I boot with init as a "hello
> > world" program everything behaves as expected (there are two in the image
> > for testing purposes, /tools/bin/hello-dynamic and
> > /tools/bin/hello-static).  But if you boot with init=/tools/bin/bash it
> > hangs.  And so do the busybox shells.
>
> I think there is a problem with the dynamic loader, I get a bus error
> when running the programs on real Sparc.

Huh.  That's odd because hello-dynamic is using the dynamic loader.  (That's 
why there's a hello-dynamic and a hello-static.)

It's entirely possibly that qemu and real sparc hardware are behaving 
differently, but I'm not seeing this bus error under qemu.  (I haven't got 
real sparc hardware, so I can only debug against qemu...)

> If I try to run the dynamic loader, it reports on real HW as well as on
> Qemu: Standalone execution is not supported yet

The ability to run the dynamic loader as an executable and the ability to use 
it as a dynamic loader are two completely unrelated things on a modern Linux 
system.  The kernel doesn't _exec_ the library loader, it calls into it as a 
shared library.

In fact, under 2.4 if you ever mount any partitions with "noexec" you also 
need to remove the executable bit from the shared library loader, because 
otherwise you can just run the library loader and feed it any program to run 
and it'll do it for you.  (The library loader doesn't care about the noexec 
mount flag.)

Of course between 2.4 and 2.6 they added an extra check to the kernel so it 
refused to exec a program if the shared library loader that program refers to 
didn't have the executable bit set, for "security" reasons.  (And the glibc 
guys made ld-linux.so start checking the executable bit on libraries too.)  
This of course means that the old trick of removing the executable bit 
doesn't _work_ anymore, so mounting stuff "noexec" is essentially 
meaningless.  Oh well, it already was if you had something like "perl" on the 
system.  Or a command shell that could launch a shell script. :)

Note also that this is why uClibc includes its own "ldd", because the glibc 
one is just a wrapper that attempts to execute ld-linux.so with some 
debugging arguments to dump the library names.  So the glibc ldd doesn't work 
on uClibc binaries, because they're not linked against ld-linux.so.  The 
uClibc one works like readelf instead, and should work on anything.

But anyway, the ability to run a library loader as a command, and its ability 
to function _as_ a library loader, are totally unrelated.  Different entry 
points.

This talks about the issue in passing:
http://www.usenix.org/publications/library/proceedings/usenix98/freenix/record_html/lxrun-3.html

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.