Re: [PATCH] polystrap-binfmt for preparing the build host
On Wed, Jun 29, 2011 at 10:27:06AM +0200, Johannes Schauer wrote:
> Hi,
>
> On Tue, Jun 28, 2011 at 11:15:34PM +0200, Yann Dirson wrote:
> > As can be seen in your script, the use of binfmt support is not
> > without problems.
> >
> > + case $ARCH in
> > + alpha|amd64|arm|armeb|i386|m68k|mips|mipsel\
> > + |powerpc|ppc64|sh4|sh4eb|sparc|sparc64)
> > + BINFMT_ARCH=$ARCH ;;
> > + armel) BINFMT_ARCH=arm ;;
> > + lpia) BINFMT_ARCH=i386 ;; # not yet verified FIXME
> > + *) echo "unknown architecture: $ARCH"; exit 1;;
> > + esac
> >
> > The most prominent problem IMHO is that it requires a system-wide
> > setting, and that in turn ties a qemu arch name to a particular
> > distro/ABI version.
> Can you elaborate where you see the problem?
* working on arm and armel targets on the same host
* targetting squeeze and wheezy on the same host
* developpers with no root access to the build host
* experimenting with changes to the -L tree used qemu, without
simultaneously breaking builds
To put it short, /etc/qemu-binfmt/* solve a per-user problem in a
system-wide manner. This is bad in itself.
> I'm not sure whether you dont understand the problem that is to be
> solved or whether I understand how you suggest something I dont see a
> need to be fixed - please explain.
>
> The $ARCH variable is being set in the config file and determines for
> what debian architecture a multistrap is done. To figure out which
> qemu-*-static binary to copy in the root directory, the above lines are
> evaluated - how do you think that can be improved?
As seen above, there is no bijection between ARCH and BINFMT_ARCH, and
several ARCH can map to a single /etc/qemu-binfmt/$BINFMT_ARCH/.
OTOH, when we're at the point of running qemu-*-static, we have
already produced a rootfs that can be used by qemu to locate the libs,
and which holds precisely those libs that would be used on the target
system. So why would we want to use another tree forced onto all
users ?
Incidentally, I was given a suggestion to solve the problem, that
should prove easier to implement that the ptrace-based approach, and
whose description will hopefully make things more clear:
Instead of having qemu-*-static directly called by binfmt, we could
call a wrapper script. That wrapper would be able to pass the -L flag
to qemu, depending on caller's choice, eg. through the use of an
envvar. If no envvar was set, then it could fall back to the
system-default tree if any.
What annoys me in this approach, are the possible security
implications of letting a user influence running binaries. I suspect
this could be applied to attack the system via setuid foreign
binaries. The user mechanism should at least be ignored in that case,
much like LD_* envvars in the same case.
And that mechanism would be in conflict with the current
qemu-user-static package, so coordination with the qemu maints will be
required.
--
Yann
Reply to: