RFC: linux-user: preserving argv[0] of the original binary in context of binfmt-misc

* RFC: linux-user: preserving argv[0] of the original binary in context of binfmt-misc
@ 2021-02-14 15:25 Michael Tokarev
  2021-02-14 15:45 ` no-reply
  2021-03-05 17:53 ` Peter Maydell
  0 siblings, 2 replies; 5+ messages in thread
From: Michael Tokarev @ 2021-02-14 15:25 UTC (permalink / raw)
  To: qemu-devel

Hi!

As known for a long time, qemu's linux-user, when invoked in context of binfmt-misc mechanism,
does not preserve the original argv[0] element, so some software which relies on argv[0] is
not functioning under qemu-user.  When run this way, argv[0] of the program being run under
qemu-user points to this qemu-user binary, instead of being what has been used to spawn the
original binary.

There's an interpreter flag in binfmt handling in recent kernels, P, or preserve, which meant
to pass 3 extra first arguments to the binfmt interpeter, - namely, the path to interpreter
itself, the argv[0] as used when spawning the original binary, and the actual path of the
said binary. But qemu-user/main does not handle this situation, - it should be prepared for
this unusual way of being invoked.

There are several hackish solutions exists on this theme used by downstreams, which introduces
a wrapper program especially for binfmt registration and nothing else, uses this P flag, and
uses -argv0 qemu-user argument to pass all the necessary information to qemu-user.

But these wrappers introduce a different issue: since the wrapper executes the qemu binary,
we can't use F binfmt-misc flag anymore without copying the qemu-user binary inside any
foreign chroot being used with it.

So the possible solution is to made qemu-user aware of this in-kernel binfmt mechanism,
which I implemented for Debian for now, as a guinea pig :)

Since the original problem is the proper handling of programs which depend on their own
name in argv[0], the proposed solution is also based on the program name, - this time
it is the name under which qemu-user binary is called.

I introduced a special name for qemu-user binaries to be used _only_ for binfmt registration.
This is, in my case, /usr/libexec/qemu-binfmt/foo-binfmt-P - where "foo" is the architecture
name, and "-binfmt-P" is the literal suffix. This name is just a (sym)link to /usr/bin/qemu-foo,
- just an alternative name for qemu-foo, nothing more.

And added a patch for linux-user/main.c which checks suffix of its argv[0], and if it ends
up on the literal "-binfmt-P", we assume we're being called from in-kernel binfmt-misc
subsystem with the P flag enabled, which means first 3 args are: our own name, the original
argv[0], and the intended binary's path, and the rest are the arguments for the binary to
run.

At first I thought it is a hackish approach, and mentioned that in a comment in the code,
but the more I think about it, the more I like it, and the more it makes sense.

Here's the patch I used in Debian (it is not intended for upstream for now), - for comments,
what do you think? At least it seems like a good step in the right direction, finally.. :)

And we have another issue still, in the same field. Some programs executes itself by using
/proc/self/exe. This does not work under linux-user too, since this link, again, points to
the qemu binary, not the original binary being run. But this is a different story.

Thanks,

/mjt

Subject: [PATCH, HACK]: linux-user: handle binfmt-misc P flag as a separate exe name
From: Michael Tokarev <mjt@tls.msk.ru>
Date: Sat, 13 Feb 2021 13:57:52 +0300

A hackish way to distinguish the case when qemu-user binary is executed
using in-kernel binfmt-misc subsystem with P flag (preserve argv).
We register binfmt interpreter under name /usr/libexec/qemu-binfmt/qemu-foo-binfmt-P
(which is just a symlink to ../../bin/qemu-foo), and if run like that,
qemu-user binary will "know" it should interpret argv[1] & argv[2]
in a special way.

diff --git a/linux-user/main.c b/linux-user/main.c
index 24d1eb73ad..5596dab9be 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -560,6 +560,27 @@ static int parse_args(int argc, char **argv)
          }
      }

+    /* HACK alert.
+     * when run as an interpreter using kernel's binfmt-misc mechanism,
+     * we have to know where are we (our own binary), where's the binary being run,
+     * and what it's argv[0] element.
+     * Only with the P interpreter flag kernel passes all 3 elements as first 3 argv[],
+     * but we can't distinguish if we were run with or without this P flag.
+     * So we register a special name with binfmt-misc system, a name which ends up
+     * in "-binfmt-P", and if our argv[0] ends up with that, we assume we were run
+     * from kernel's binfmt with P flag and our first 3 args are from kernel.
+     */
+    if (strlen(argv[0]) > sizeof("binfmt-P") &&
+        strcmp(argv[0] + strlen(argv[0]) - sizeof("binfmt-P"), "-binfmt-P") == 0) {
+        if (argc < 3) {
+            (void) fprintf(stderr, "qemu: %s has to be run using kernel binfmt-misc subsystem\n", argv[0]);
+            exit(EXIT_FAILURE);
+        }
+        handle_arg_argv0(argv[1]);
+        exec_path = argv[2];
+        return 2;
+    }
+
      optind = 1;
      for (;;) {
          if (optind >= argc) {


^ permalink raw reply related	[flat|nested] 5+ messages in thread