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

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

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Helge Deller <deller@gmx.de> - 2023-07-17 15:00 +0200
    Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Michael Tokarev <mjt@tls.msk.ru> - 2023-07-17 15:30 +0200
      Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Helge Deller <deller@gmx.de> - 2023-07-17 20:40 +0200
        Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Helge Deller <deller@gmx.de> - 2023-07-17 20:50 +0200
          Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Helge Deller <deller@gmx.de> - 2023-07-17 22:10 +0200
            Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Michael Tokarev <mjt@tls.msk.ru> - 2023-07-17 22:30 +0200
              Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Helge Deller <deller@gmx.de> - 2023-07-17 22:40 +0200

#1154607 — Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

Hello,

Could someone please try the 3 qemu patches (and one revert) which I pushed to my "upx-fix"
branch with this binary?

It's based on top of qemu git master:
https://github.com/hdeller/qemu-hppa/commits/upx-fix
You can pull from:
git pull https://github.com/hdeller/qemu-hppa.git  upx-fix

I think those fix this bug here.

Helge

[toc] | [next] | [standalone]

#1154614

17.07.2023 15:55, Helge Deller wrote:
> Hello,
> 
> Could someone please try the 3 qemu patches (and one revert) which I pushed to my "upx-fix"
> branch with this binary?
> 
> It's based on top of qemu git master:
> https://github.com/hdeller/qemu-hppa/commits/upx-fix
> You can pull from:
> git pull https://github.com/hdeller/qemu-hppa.git  upx-fix
> 
> I think those fix this bug here.

It does not with the fstype reproducer:

$ ./qemu-arm /usr/lib/klibc/bin/fstype
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
$ _

Neither on top of master nor staging-8.0.

The segfault is about the same, with same stack trace.

/mjt

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

#1154663

This patch (hack) fixes the crash on armhf.

diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index a26200d9f3..2efa981061 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -3674,7 +3685,7 @@ int load_elf_binary(struct linux_binprm *bprm, struct image_info *info)
      * The implementation of do_brk in syscalls.c expects to be able
      * to mmap pages in this space.
      */
-    if (info->reserve_brk) {
+    if (0 && info->reserve_brk) {
         abi_ulong start_brk = HOST_PAGE_ALIGN(info->brk);
         abi_ulong end_brk = HOST_PAGE_ALIGN(info->brk + info->reserve_brk);
         target_munmap(start_brk, end_brk - start_brk);

Still wondering what the best fix is.

Without the patch this is the memory layout:
start    end      size     prot
00010000-00011000 00001000 r-x
00011000-00020000 0000f000 ---
00020000-00021000 00001000 rw-
40000000-40001000 00001000 ---
40001000-40801000 00800000 rwx
40801000-40802000 00001000 r-x
ffff0000-ffff1000 00001000 r-x
start_brk   0x00000000
end_code    0x00010a73
start_code  0x00010000
start_data  0x00020a78
end_data    0x00020cd0
start_stack 0x407ffe50
brk         0x00020cd4
entry       0x003800f9
argv_start  0x407ffe54
env_start   0x407ffe60
auxv_start  0x407fff28


With the patch, this is the layout:
start    end      size     prot
00010000-00011000 00001000 r-x
00011000-00020000 0000f000 ---
00020000-00021000 00001000 rw-
00021000-00380000 0035f000 ---
00380000-0038d000 0000d000 r-x
0038d000-0039c000 0000f000 ---
0039c000-0039d000 00001000 rw-
0039d000-0039f000 00002000 rw-
0039f000-01021000 00c82000 ---
40000000-40001000 00001000 ---
40001000-40801000 00800000 rwx
40801000-40802000 00001000 r-x
ffff0000-ffff1000 00001000 r-x
start_brk   0x00000000
end_code    0x00010a73
start_code  0x00010000
start_data  0x00020a78
end_data    0x00020cd0
start_stack 0x407ffe50
brk         0x00020cd4
entry       0x003800f9
argv_start  0x407ffe54
env_start   0x407ffe60
auxv_start  0x407fff28

As can be seen, the memory segment of "entry" at 0x003800f9
has been unmapped when releasing the "reserve_brk" region.
Since qemu can't then fetch the instructions, it crashes immediately.

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

#1154665

> Without the patch this is the memory layout:
> start    end      size     prot
> 00010000-00011000 00001000 r-x
> 00011000-00020000 0000f000 ---
> 00020000-00021000 00001000 rw-
> 40000000-40001000 00001000 ---
> 40001000-40801000 00800000 rwx
> 40801000-40802000 00001000 r-x

The difference between armhf and amd64 regarding the fstype binary is:
armhf:
fstype loads at 00010000 and klibc.so loads at 40000000
for amd64:
fstype loads at 00400000 and klibc.so loads at 00200000

So, on amd64 the brk region is above both elf binaries,
while on armhf if clashes with the klibc areas.

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

#1154681

This patch seems to work. Tested with qemu-arm and qemu-amd64.

diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index a26200d9f3..b583018591 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -3615,6 +3631,13 @@ int load_elf_binary(struct linux_binprm *bprm, struct image_info *info)

     if (elf_interpreter) {
         load_elf_interp(elf_interpreter, &interp_info, bprm->buf);
+        /*
+         * adjust brk address if the interpreter was loaded above the main
+         * executable, e.g. happens with static binaries on armhf
+         */
+        if (interp_info.brk > info->brk) {
+            info->brk = interp_info.brk;
+        }

         /* If the program interpreter is one of these two, then assume
            an iBCS2 image.  Otherwise assume a native linux image.  */

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

#1154684

17.07.2023 22:58, Helge Deller wrote:
> This patch seems to work. Tested with qemu-arm and qemu-amd64.

Wow!

> diff --git a/linux-user/elfload.c b/linux-user/elfload.c
> index a26200d9f3..b583018591 100644
> --- a/linux-user/elfload.c
> +++ b/linux-user/elfload.c
> @@ -3615,6 +3631,13 @@ int load_elf_binary(struct linux_binprm *bprm, struct image_info *info)
> 
>       if (elf_interpreter) {
>           load_elf_interp(elf_interpreter, &interp_info, bprm->buf);
> +        /*
> +         * adjust brk address if the interpreter was loaded above the main
> +         * executable, e.g. happens with static binaries on armhf

Guess you mean dynamic binaries?  the klibc binaries we used are dynamic, no?


> +         */
> +        if (interp_info.brk > info->brk) {
> +            info->brk = interp_info.brk;
> +        }

Heh.  So it clashes with brk. Nice... ;)

You should ping upstream about this one before 8.1 is out, I think.

/mjt

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

#1154687

On 7/17/23 22:21, Michael Tokarev wrote:
> 17.07.2023 22:58, Helge Deller wrote:
>> This patch seems to work. Tested with qemu-arm and qemu-amd64.
>
> Wow!
>
>> diff --git a/linux-user/elfload.c b/linux-user/elfload.c
>> index a26200d9f3..b583018591 100644
>> --- a/linux-user/elfload.c
>> +++ b/linux-user/elfload.c
>> @@ -3615,6 +3631,13 @@ int load_elf_binary(struct linux_binprm *bprm, struct image_info *info)
>>
>>       if (elf_interpreter) {
>>           load_elf_interp(elf_interpreter, &interp_info, bprm->buf);
>> +        /*
>> +         * adjust brk address if the interpreter was loaded above the main
>> +         * executable, e.g. happens with static binaries on armhf
>
> Guess you mean dynamic binaries?  the klibc binaries we used are dynamic, no?

Well, it's a static binary, but with dynamic interpreter:

deller@abel:~$ file fstype
fstype: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, interpreter /lib/klibc-m13AniKHUCMUNN8mXSUhIi8CUSA.so, BuildID[sha1]=127738bcbae6cad12468cc4182c9b289c3452864, stripped

>> +         */
>> +        if (interp_info.brk > info->brk) {
>> +            info->brk = interp_info.brk;
>> +        }
>
> Heh.  So it clashes with brk. Nice... ;)
>
> You should ping upstream about this one before 8.1 is out, I think.

I've queued up quite some other brk() fixes here:
https://github.com/hdeller/qemu-hppa/tree/upx-strace-fix-2
They hopefully fix all remaining issues.

Helge

[toc] | [prev] | [standalone]

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

csiph-web