qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] linux-user: Add binfmt wrapper


From: Joakim Tjernlund
Subject: Re: [Qemu-devel] [PATCH] linux-user: Add binfmt wrapper
Date: Wed, 16 Jul 2014 13:38:07 +0200

Riku Voipio <address@hidden> wrote on 2014/07/16 08:54:45:
> 
> On Tue, Jul 15, 2014 at 05:11:48PM +0200, Joakim Tjernlund wrote:
> > Riku Voipio <address@hidden> wrote on 2014/07/15 16:12:26:
> > > On Mon, Jul 14, 2014 at 05:38:49PM +0200, Joakim Tjernlund wrote:
> > > > Alexander Graf <address@hidden> wrote on 2014/07/14 17:21:33:
> > > > > On 14.07.14 16:38, Joakim Tjernlund wrote:
> > > > > > The popular binfmt-wrapper patch adds an additional
> > > > > > executable which mangle argv suitable for binfmt flag P.
> > > > > > In a chroot you need the both (statically linked) qemu-$arch
> > > > > > and qemu-$arch-binfmt-wrapper. This is sub optimal and a
> > > > > > better approach is to recognize the -binfmt-wrapper extension
> > > > > > within linux-user(qemu-$arch) and mangle argv there.
> > > > > > This just produces on executable which can be either copied to
> > > > > > the chroot or bind mounted with the appropriate 
-binfmt-wrapper
> > > > > > suffix.
> > > > > >
> > > > > > Signed-off-by: Joakim Tjernlund 
<address@hidden>
> > > > > 
> > > > > Please make sure to CC Riku on patches like this - he is the 
> > linux-user 
> > > > > maintainer.
> > > > 
> > > > Doesn't he read the devel list? Anyhow CC:ed
> > > 
> > > I do - but CC gets directly to my inbox while qemu-devel goes to an
> > > folder.
> > > 
> > > I take from this discussion, that this patch has been superceded by 
the
> > > Patch at: http://patchwork.ozlabs.org/patch/369770/ ?
> > 
> > BTW, any chance qemu binfmt could fixup the ps output from within a 
> > container:
> >  jocke-ppc2 ~ # ps uaxww
> > USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME 
COMMAND
> > root         1  0.1  0.0 4138016 7600 ?        Ss   17:02   0:00 
> > /usr/bin/qemu-ppc /sbin/init /sbin/init
> > root        79  0.0  0.0 4138016 5792 ?        Ss   17:02   0:00 
> > /usr/bin/qemu-ppc /usr/sbin/sshd /usr/sbin/sshd
> > root       293  0.0  0.0 4137952 4072 ?        Ss   17:02   0:00 
> > /usr/bin/qemu-ppc /bin/busybox /bin/busybox udhcpc -x 
hostname:jocke-ppc2 
> > --interface=eth0 --now --script=/lib/netifrc/sh/udhcpc-hook.sh 
> > --pidfile=/var/run/udhcpc-eth0.pid
> > root       334  0.3  0.0 4138016 5964 tty1     Ss+  17:02   0:00 
> > /usr/bin/qemu-ppc /sbin/agetty /sbin/agetty 38400 tty1 linux
> > root       335  3.1  0.0 4138048 7064 console  Ss   17:02   0:00 
> > /usr/bin/qemu-ppc /bin/login /bin/login -- root
> > root       336  3.3  0.0 4138016 9764 console  S    17:02   0:00 
> > /usr/bin/qemu-ppc /bin/bash -bash
> > root       340  0.0  0.0 4138016 6336 ?        R+   Jul10   0:00 
/bin/ps 
> > ps uaxww
> > 
> > As you can see, qemu-ppc is visible. 
> 
> This isn't something binfmt could do. ps uses /proc/$pid/exe to map the
> right binary. However, qemu already fixes /proc/self/exe to point to
> right file - as you can see from the last line where "ps uaxww" doesn't
> have qemu shown. So it would be possible to make do_open() in syscall.c 
do
> similar mapping for /proc/$pid/exe. 
> 
> Exactly how and when the qemu processes should be hidden within qemu
> needs careful thought thou. A naive approach would check if
> /proc/$pid/exe points to same binary as /proc/self/exe, hiding at least
> same architecture qemu processes.

Took a look at do_open(), what horror to read what you do there.
How on earth is this supposed to work?
You don't separate normal qemu invocation from binfmt, only adjust
"self" stuff, always only remove one entry(binfmt P flag is 2 entries)

Reasonably this hiding should only be performed when started by binfmt?
What are the other uses for ?

 Jocke



reply via email to

[Prev in Thread] Current Thread [Next in Thread]