Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1025348 > unrolled thread

Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries Thorsten Glaser <tg@mirbsd.de> - 2020-09-16 19:00 +0200
    Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2020-09-16 19:20 +0200
      Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries Michael Tokarev <mjt@tls.msk.ru> - 2020-09-16 20:00 +0200
      Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries Thorsten Glaser <tg@mirbsd.de> - 2020-09-16 21:00 +0200
    Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries Andreas Schwab <schwab@linux-m68k.org> - 2020-09-16 21:20 +0200
      Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries Michael Tokarev <mjt@tls.msk.ru> - 2020-09-16 21:30 +0200
        Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries Thorsten Glaser <tg@mirbsd.de> - 2020-09-16 21:50 +0200
    Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries Michael Tokarev <mjt@tls.msk.ru> - 2020-09-16 22:10 +0200
    Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries Michael Tokarev <mjt@tls.msk.ru> - 2020-09-17 10:00 +0200
      Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries Thorsten Glaser <tg@mirbsd.de> - 2020-09-17 23:50 +0200
        Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries Finn Thain <fthain@telegraphics.com.au> - 2020-09-18 01:40 +0200
        Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries Thorsten Glaser <tg@debian.org> - 2020-09-19 22:10 +0200
    Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries Michael Tokarev <mjt@tls.msk.ru> - 2020-09-17 10:20 +0200
    Bug#970460: [Bug libc/23960] [2.28 Regression]: New getdents{64} implementation breaks qemu-user Thorsten Glaser <tg@mirbsd.de> - 2020-10-03 01:30 +0200

#1025348 — Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries

[Multipart message — attachments visible in raw view] — view raw

Package: qemu-user
Version: 1:5.1+dfsg-4
Severity: important
X-Debbugs-Cc: tg@mirbsd.de, debian-68k@lists.debian.org

I’m attaching a test program that does the following:

• if argv[1] is "-" it just outputs argv[0] and argv[1]
• otherwise it also execve(2)s argv[1] with its argv[0] set to "meow"

I’ve installed the extra packages:
• gcc-arm-linux-gnueabi
• libc6-dev-armel-cross


tglase@tglase-nb:~ $ gcc -Wall -Wextra -o native tst.c
1|tglase@tglase-nb:~ $ ./native ./native
argv[0]: ./native
argv[1]: ./native
calling...
argv[0]: meow
argv[1]: -
not calling
tglase@tglase-nb:~ $ arm-linux-gnueabi-gcc -o cross tst.c -static
tglase@tglase-nb:~ $ ./cross ./cross
argv[0]: ./cross
argv[1]: ./cross
calling...
argv[0]: ./cross
argv[1]: -
not calling
tglase@tglase-nb:~ $ ./cross ./native
argv[0]: ./cross
argv[1]: ./native
calling...
argv[0]: meow
argv[1]: -
not calling
tglase@tglase-nb:~ $ ./native ./cross
argv[0]: ./native
argv[1]: ./cross
calling...
argv[0]: ./cross
argv[1]: -
not calling


As you can see, if the callee of an exec is a qemu-user target,
argv[0] is trashed.

This, among other things, makes qemu-user-static-based buildds unworkable.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.0-2-amd64 (SMP w/2 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages qemu-user depends on:
ii  libc6         2.31-3
ii  libcapstone3  4.0.1+really+3.0.5-2
ii  libgcc-s1     10.2.0-7
ii  libglib2.0-0  2.66.0-1
ii  libgnutls30   3.6.15-2
ii  libstdc++6    10.2.0-7
ii  zlib1g        1:1.2.11.dfsg-2

Versions of packages qemu-user recommends:
ii  qemu-user-static [qemu-user-binfmt]  1:5.1+dfsg-4

Versions of packages qemu-user suggests:
ii  sudo  1.9.1-2

-- no debconf information

[toc] | [next] | [standalone]

#1025350

> On Sep 16, 2020, at 6:57 PM, Thorsten Glaser <tg@mirbsd.de> wrote:
> 
> I’m attaching a test program that does the following:
> 
> • if argv[1] is "-" it just outputs argv[0] and argv[1]
> • otherwise it also execve(2)s argv[1] with its argv[0] set to "meow"

That’s been fixed upstream and can be configured with the qemu-binfmt.sh script and the option “preserved=yes”.

Also, this would be an upstream bug, not a Debian bug :).

Adrian

[toc] | [prev] | [next] | [standalone]

#1025359

16.09.2020 20:15, John Paul Adrian Glaubitz wrote:
> 
>> On Sep 16, 2020, at 6:57 PM, Thorsten Glaser <tg@mirbsd.de> wrote:
>>
>> I’m attaching a test program that does the following:
>>
>> • if argv[1] is "-" it just outputs argv[0] and argv[1]
>> • otherwise it also execve(2)s argv[1] with its argv[0] set to "meow"
> 
> That’s been fixed upstream and can be configured with the qemu-binfmt.sh script and the option “preserved=yes”.

Where it's been fixed? current git version of scripts/qemu-binfmt-conf.sh
does not have 'preserved' option, and if the P flag is set when registering
binfmt, the kernel will _prepend_ additional argv[0] element which is not
expected by current linux-user/main.c code (so the tst.c example will be
running with 3 args, not 2).

Thanks,

/mjt

[toc] | [prev] | [next] | [standalone]

#1025362

John Paul Adrian Glaubitz dixit:

>That’s been fixed upstream and can be configured with the
>qemu-binfmt.sh script and the option “preserved=yes”.

$ locate qemu-binfmt.sh | wc
      0       0       0

Also, why didn’t you fix that on the m68k and sh4 qemu buildds then? ;-)

Meow,
//mirabilos
-- 
> Wish I had pine to hand :-( I'll give lynx a try, thanks.

Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k.a. {news.gmane.org/nntp}#news.gmane.linux.debian.ports.68k in pine

[toc] | [prev] | [next] | [standalone]

#1025365

openSUSE carries a patch for this issue:

https://build.opensuse.org/package/view_file/Virtualization/qemu/linux-user-add-binfmt-wrapper-for-argv-0.patch?expand=1

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

[toc] | [prev] | [next] | [standalone]

#1025366

16.09.2020 22:01, Andreas Schwab wrote:
> openSUSE carries a patch for this issue:

We can do much easier than a separate wrapper.
Since we register binfmt entries in the same package where
the qemu-user binaries are, we can patch qemu (a one-liner)
to always expect the P flag.  I thin I'll go this route.

Thank you for all the findings!

/mjt

[toc] | [prev] | [next] | [standalone]

#1025369

Michael Tokarev dixit:

>Since we register binfmt entries in the same package where
>the qemu-user binaries are, we can patch qemu (a one-liner)
>to always expect the P flag.  I thin I'll go this route.

Thanks!

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
	-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

[toc] | [prev] | [next] | [standalone]

#1025370

16.09.2020 22:55, John Paul Adrian Glaubitz wrote:

> It's called "--persistent yes", not preserve, my bad.

It is entirely different thing, --persistent (or --fix-binary. F flag)
is here for quite some time and helps with chroots and the like.

BTW, it turned out not that simple as I thought, the wrapper as
used by SUSE is still needed - or else it's impossible to distinguish
between direct qemu-foo invocation and the same invocation using
binfmt.

/mjt

[toc] | [prev] | [next] | [standalone]

#1025408

17.09.2020 10:08, John Paul Adrian Glaubitz wrote:
> On 9/16/20 8:42 PM, Thorsten Glaser wrote:
>> John Paul Adrian Glaubitz dixit:
>>
>>> That’s been fixed upstream and can be configured with the
>>> qemu-binfmt.sh script and the option “preserved=yes”.
>>
>> $ locate qemu-binfmt.sh | wc
>>       0       0       0

It is scripts/qemu-binfmt-conf.sh script inside the qemu sources.
It was a fork of debian's d/update-binfmts.sh, updated for other
use cases.

> Well, to be honest, you should never use the Debian QEMU package. It's almost
> always very outdated and would lack important patches like these. It's easier
> to use local builds from git.

You should not use upstream git of qemu, since it too lacks
important patches like this, - please don't suggest people
to use outdated sources.. :)

(just as a matter of fact, debian usually has new version of
qemu the next day it is released, and I usually keep it up
to date in backports. With debian stable and current qemu 5.
we have a bit of delay since there are a few other things to
backport, but we have 5.0 there).

/mjt

[toc] | [prev] | [next] | [standalone]

#1025490

Michael Tokarev dixit:
> 17.09.2020 10:56, John Paul Adrian Glaubitz wrote:
>> On 9/17/20 9:49 AM, Michael Tokarev wrote:
>>>17.09.2020 10:08, John Paul Adrian Glaubitz wrote:
>>>> On 9/16/20 8:42 PM, Thorsten Glaser wrote:
>>>>> John Paul Adrian Glaubitz dixit:
>>>>>
>>>>>> That’s been fixed upstream and can be configured with the
>>>>>> qemu-binfmt.sh script and the option “preserved=yes”.
>>>>>
>>>>> $ locate qemu-binfmt.sh | wc
>>>>>       0       0       0
>>>
>>>It is scripts/qemu-binfmt-conf.sh script inside the qemu sources.
>>>It was a fork of debian's d/update-binfmts.sh, updated for other
>>>use cases.

Ah, okay.

>>>> Well, to be honest, you should never use the Debian QEMU package. It's almost
>>>> always very outdated and would lack important patches like these. It's easier
>>>> to use local builds from git.

Erm, excuse me?!?!?!

Of *course*, when developing for (or on, most of the time)
Debian, I use as many tools in the form packaged in Debian
as possible.

When developing *for* Debian (that is, things that eventually
get uploaded), I think it’s correct to even have the *expectation*
that only packaged things get used throughout the chain.

If your qemu buildds have errors, where else would we fix them?
Also, how else would maintainers reproduce them?

I reported this bug *because* your qemu buildds had errors
building mksh and because I was able to reproduce them.

I *really* _expect_ qemu buildds to use the packaged version
of qemu-user, ideally the one from sid.

>>>You should not use upstream git of qemu, since it too lacks
>>>important patches like this, - please don't suggest people
>>>to use outdated sources.. :)

Thanks for the confirmation from the maintainer.

>> I think I'm one of the heaviest users of QEMU inside Debian and if
>> I had stuck with the Debian version of QEMU, the m68k and sh4 ports
>> would not be able to keep up due to QEMU issues. Laurent will confirm
>> the number of bugs I reported and that got fixed.

That asks for trying to work with the Debian maintainer of the
affected package (qemu in this case) to get the bugs not only
fixed but also available to Debian users. (Yes I know, but see
below.)

>>>(just as a matter of fact, debian usually has new version of
>>>qemu the next day it is released, and I usually keep it up
>>>to date in backports. With debian stable and current qemu 5.
>>>we have a bit of delay since there are a few other things to
>>>backport, but we have 5.0 there).

But a buildd can run unstable anyway, and especially with
qemu-user-static this should be a given.

>> Well, the first thing would be to switch QEMU in Debian to finally
>> use systemd-binfmt instead of the old binfmt-support package,
>> something that has happened in other distributions long ago.

Absolutely not! That will break it on all my systems.

> This will make other packages using binfmt-support to work with
> the systemd binfmt registration instantly, and things will continue
> to work if systemd is not in use (for those who prefer sysvinit
> or other init mechanisms, fwiw).

Thanks.

>>>>> Also, why didnbt you fix that on the m68k and sh4 qemu buildds then? ;-)
>>>>
>>>>I did. But I'm updating the QEMU version on the buildds from time to time
>>>>by rebasing with git master and then I drop all the patches that have been
>>>>applied upstream.

Arrgh, no. Please use the packaged version. That avoids
many issues and ensures trust.

>> If you are willing to cooperate though, I'm happy to point you to
>> all the patches necessary to address all issues that we observed.
>
> I'm definitely interested in things being fixed in the end, tho
> it isn't obvious how much backporting should be done to _testing_
> version in Debian.

Thanks for being open to patching the version in Debian. Not all
maintainers are agreeable like that, unfortunately.

I know the burden of carrying local patches, but backports would
have been already accepted upstream, are scheduled to be removed
with a new upstream release, and are less likely to break things.
Patches that fix things for an architecture, whether guest or host,
should be considered IMHO, even if it’s not a release architecture,
at least during normal development, i.e. not just before a freeze
but all the other time.

>> There is also an important glibc patch necessary to unbreak qemu-user
>> that still hasn't been merged in glibc upstream or in Debian's glibc
>> package [1, 2].

>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916276
>> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=23960

This is the first time I’m being made aware of that. (I had wondered
about the +qemu releases in unreleased.) This looks like another case
of prodding maintainers (and, perhaps, looking whether it can’t be
fixed in qemu as well).

But that’s what uploads to dpo unreleased are for, after all. And
if done with care and following normal Debian rules (and, incidentally,
being made using _only_ tools from Debian) I consider unreleased part
of Debian on that specific architecture (as it’s a ports-only thing
anyway).

bye,
//mirabilos
-- 
<ch> you introduced a merge commit        │<mika> % g rebase -i HEAD^^
<mika> sorry, no idea and rebasing just fscked │<mika> Segmentation
<ch> should have cloned into a clean repo      │  fault (core dumped)
<ch> if I rebase that now, it's really ugh     │<mika:#grml> wuahhhhhh

[toc] | [prev] | [next] | [standalone]

#1025494

On Thu, 17 Sep 2020, Thorsten Glaser wrote:

> 
> >>>> Well, to be honest, you should never use the Debian QEMU package. 
> >>>> It's almost always very outdated and would lack important patches 
> >>>> like these. It's easier to use local builds from git.
> 
> Erm, excuse me?!?!?!
> 

It's an over-statement. Let's not over-react. Just read "not presently" in 
place of "never".

> ...
> >> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916276
> >> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=23960
> 
> This is the first time I'm being made aware of that.

Thanks for the link, Adrian, and thanks for raising this issue upstream. 
It's a monumental mess.

[toc] | [prev] | [next] | [standalone]

#1025687

Dixi quod…
>Michael Tokarev dixit:
>> 17.09.2020 10:56, John Paul Adrian Glaubitz wrote:
>>> There is also an important glibc patch necessary to unbreak qemu-user
>>> that still hasn't been merged in glibc upstream or in Debian's glibc
>>> package [1, 2].
>
>>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916276
>>> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=23960
>
>This is the first time I’m being made aware of that. (I had wondered
>about the +qemu releases in unreleased.) This looks like another case
>of prodding maintainers (and, perhaps, looking whether it can’t be
>fixed in qemu as well).

I prodded maintainers, see below, but the latter looks like it’ll be
needed.

---------- Forwarded message ----------
From: Thorsten Glaser <tg@debian.org>
Message-ID: <Pine.BSM.4.64L.2009191949200.20959@herc.mirbsd.org>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: 916276@bugs.debian.org
Date: Sat, 19 Sep 2020 19:51:28 +0000 (UTC)
Subject: Re: Bug#916276: glibc: Please add prelimenary patch to fix regression
    on qemu-user

Hi,

>The patch is basically replacing the getdents64 syscall by the getdents
>one. This means that applying this patch would make debian differ with
>regards to other distributions in the syscalls that are used for the
>same binaries. In turns it is likely going to affect binaries that are
>using seccomp and only allow the getdents64 and not the getdents one.

ah, indeed.

>I therefore don't think this is not reasonable to include such a fix on
>our glibc. It would fix the qemu-user case but likely break random
>binaries.

OK, thanks for the explanation.

Let’s hope this can be fixed, somehow, in qemu itself and/or the kernel.

bye,
//mirabilos
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
	-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

[toc] | [prev] | [next] | [standalone]

#1025413

17.09.2020 10:56, John Paul Adrian Glaubitz wrote:
> On 9/17/20 9:49 AM, Michael Tokarev wrote:
>> You should not use upstream git of qemu, since it too lacks
>> important patches like this, - please don't suggest people
>> to use outdated sources.. :)
> 
> I think I'm one of the heaviest users of QEMU inside Debian and if
> I had stuck with the Debian version of QEMU, the m68k and sh4 ports
> would not be able to keep up due to QEMU issues. Laurent will confirm
> the number of bugs I reported and that got fixed.

You were referring to particular example of a patch which is
NOT merged upstream, - not your other heavy usages. And this
is exactly what my joke about - if lack of this patch makes
source outdated, it should not be used, hence upstream git
is also outdated, nothing more nothing less. I wont deny
other issues being addressed upstream all the time, and
I definitely wont fight against Debian stable policy.

>> (just as a matter of fact, debian usually has new version of
>> qemu the next day it is released, and I usually keep it up
>> to date in backports. With debian stable and current qemu 5.
>> we have a bit of delay since there are a few other things to
>> backport, but we have 5.0 there).
> 
> Well, the first thing would be to switch QEMU in Debian to finally
> use systemd-binfmt instead of the old binfmt-support package,
> something that has happened in other distributions long ago.

This is debatable. First of all I didn't know binfmt-support is
"old", just checked its pages and description, - nowhere they
mention it is deprecated or something.  And to me, I think
"switching to" should happen *in* that package, ie, when
binfmt-support and systemd cooperates, say, binfmt-support prepares
stuff for systemd and does nothing when booted under systemd.
This will make other packages using binfmt-support to work with
the systemd binfmt registration instantly, and things will continue
to work if systemd is not in use (for those who prefer sysvinit
or other init mechanisms, fwiw).

It's trivial to "switch" to systemd binfmt support on qemu part.
But I don't want to do it without a good reason, and I don't
actually see binfmt-support being "bad" in some way, - what's the
problem with it exactly?

> If you are willing to cooperate though, I'm happy to point you to
> all the patches necessary to address all issues that we observed.

I'm definitely interested in things being fixed in the end, tho
it isn't obvious how much backporting should be done to _testing_
version in Debian.

/mjt

[toc] | [prev] | [next] | [standalone]

#1027341 — Bug#970460: [Bug libc/23960] [2.28 Regression]: New getdents{64} implementation breaks qemu-user

Hi Adrian,

could you work around the problem by starting an i386 VM on
your amd64 system, and then running the qemu-user buildds on
that? The return values from the syscalls will natively be
correct 32 bit there…

In the meantime, someone found that this bug also hits without
any qemu involvement:


danny.milo at gmail dot com dixit:

>https://sourceware.org/bugzilla/show_bug.cgi?id=23960

>--- Comment #58 from Danny Milosavljevic <danny.milo at gmail dot com> ---
>The title should be changed to be more general because this does not only break
>qemu-user.  In fact, mentioning qemu would make it seem that it can be fixed in
>qemu-user--which it can't.
>
>The same happens on aarch64 if running armhf executables (no qemu anywhere).
[…]


It was also found that this cannot be fixed “only” in qemu.
The GNU libc people are discussing…

bye,
//mirabilos
-- 
16:47⎜«mika:#grml» .oO(mira ist einfach gut....)      23:22⎜«mikap:#grml»
mirabilos: und dein bootloader ist geil :)    23:29⎜«mikap:#grml» und ich
finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann
gleich mal auf usb-stick installieren	-- Michael Prokop über MirOS bsd4grml

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web