From: Ben Hutchings <benh@debian.org>
To: "Richard Henderson" <richard.henderson@linaro.org>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Michael Tokarev" <mjt@tls.msk.ru>,
919921@bugs.debian.org, "Laurent Vivier" <laurent@vivier.eu>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Bug#919921: qemu-user Linux ELF loader fails to handle pure BSS segments
Date: Mon, 07 Oct 2019 18:29:19 +0100 [thread overview]
Message-ID: <0243ea3a388f77dd8002853310081af23a7d787b.camel@debian.org> (raw)
In-Reply-To: <0fd131fc-3802-dde3-e21c-6c3ea5a444e3@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 4155 bytes --]
On Tue, 2019-01-22 at 21:31 -0800, Richard Henderson wrote:
> On 1/22/19 1:39 AM, Philippe Mathieu-Daudé wrote:
> > Hi Ben,
> >
> > On 1/22/19 6:43 AM, Michael Tokarev wrote:
> > > Forwarding to qemu-devel@
> > > http://bugs.debian.org/919921
> > >
> > > Thanks!
> > >
> > > 20.01.2019 20:55, Ben Hutchings wrote:
> > > > Package: qemu-user
> > > > Version: 1:3.1+dfsg-2
> > > > Severity: normal
> > > > Tags: patch
> > > >
> > > > I've been building and testing klibc across many architectures using
> > > > qemu-user, and I found that qemu-user fails to load a few programs on
> > > > a few architectures, reporting an EINVAL error code. Here's the
> > > > "readelf -l" output for one such program:
> > > >
> > > > Elf file type is EXEC (Executable file)
> > > > Entry point 0x10000100
> > > > There are 5 program headers, starting at offset 52
> > > > Program Headers:
> > > > Type Offset VirtAddr PhysAddr FileSiz MemSiz
> > > > Flg Align
> > > > PHDR 0x000034 0x10000034 0x10000034 0x000a0 0x000a0
> > > > R 0x4
> > > > INTERP 0x0000d4 0x100000d4 0x100000d4 0x0002a 0x0002a
> > > > R 0x1
> > > > [Requesting program interpreter:
> > > > /lib/klibc-R7FVdnsTBUFpWPgCV6FR07b-mf8.so]
> > > > LOAD 0x000000 0x10000000 0x10000000 0x002f8 0x002f8 R
> > > > E 0x10000
> > > > LOAD 0x010000 0x10020000 0x10020000 0x00000 0x08000
> > > > RW 0x10000
> > > > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000
> > > > RWE 0x10
> > > > Section to Segment mapping:
> > > > Segment Sections...
> > > > 00
> > > > 01 .interp
> > > > 02 .interp .text .rodata .eh_frame
> > > > 03 .bss
> > > > 04
> > > >
> > > > The unusual feature of this program, and all the others that failed,
> > > > is that there is a LOAD segment with a file-size of 0 (i.e. only BSS,
> > > > no initialised data). load_elf_image() will try to mmap() initialised
> > > > data for this section even though there is none and a length of 0 is
> > > > invalid.
> > > >
> > > > The change that seems to fix this is to skip the mmap() in this case:
Is there a reason why my fix can't be applied? Do I need to open a bug
report in Launchpad for this?
Ben.
> > > > --- a/linux-user/elfload.c
> > > > +++ b/linux-user/elfload.c
> > > > @@ -2316,11 +2316,13 @@ static void load_elf_image(const char *i
> > > > vaddr_ps = TARGET_ELF_PAGESTART(vaddr);
> > > > vaddr_len = TARGET_ELF_PAGELENGTH(eppnt->p_filesz +
> > > > vaddr_po);
> > > > - error = target_mmap(vaddr_ps, vaddr_len,
> > > > - elf_prot, MAP_PRIVATE | MAP_FIXED,
> > > > - image_fd, eppnt->p_offset - vaddr_po);
> > > > - if (error == -1) {
> > > > - goto exit_perror;
> > > > + if (vaddr_len != 0) {
> >
> > This is probably not the good fix, since now your process doesn't have
> > anything mapped to use his BSS :)
>
> Not true. The mapping happens in zero_bss.
>
> > What about this fix instead, using the segment memory size rather than
> > the file size:
> >
> > -- >8 --
> > @@ -2314,7 +2314,7 @@ static void load_elf_image(const char *image_name,
> > int image_fd,
> > vaddr = load_bias + eppnt->p_vaddr;
> > vaddr_po = TARGET_ELF_PAGEOFFSET(vaddr);
> > vaddr_ps = TARGET_ELF_PAGESTART(vaddr);
> > - vaddr_len = TARGET_ELF_PAGELENGTH(eppnt->p_filesz + vaddr_po);
> > + vaddr_len = TARGET_ELF_PAGELENGTH(eppnt->p_memsz + vaddr_po);
> >
> > error = target_mmap(vaddr_ps, vaddr_len,
> > elf_prot, MAP_PRIVATE | MAP_FIXED,
>
> No, there's only filesz bytes in the file. I'd expect zero_bss to map over the
> extra that you just mapped, but it doesn't help.
>
>
> r~
--
Ben Hutchings - Debian developer, member of kernel, installer and LTS teams
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-10-07 18:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <154800690066.11444.6761064786302350654.reportbug@deadeye.wl.decadent.org.uk>
2019-01-22 5:43 ` [Qemu-devel] Bug#919921: qemu-user Linux ELF loader fails to handle pure BSS segments Michael Tokarev
2019-01-22 9:39 ` Philippe Mathieu-Daudé
2019-01-23 5:31 ` Richard Henderson
2019-10-07 17:29 ` Ben Hutchings [this message]
2019-10-07 17:34 ` Philippe Mathieu-Daudé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0243ea3a388f77dd8002853310081af23a7d787b.camel@debian.org \
--to=benh@debian.org \
--cc=919921@bugs.debian.org \
--cc=laurent@vivier.eu \
--cc=mjt@tls.msk.ru \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).