diff options
Diffstat (limited to 'results/classifier/zero-shot/108/other/1886097')
| -rw-r--r-- | results/classifier/zero-shot/108/other/1886097 | 86 |
1 files changed, 86 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/other/1886097 b/results/classifier/zero-shot/108/other/1886097 new file mode 100644 index 000000000..86492d52f --- /dev/null +++ b/results/classifier/zero-shot/108/other/1886097 @@ -0,0 +1,86 @@ +other: 0.780 +semantic: 0.774 +graphic: 0.769 +debug: 0.742 +permissions: 0.703 +network: 0.673 +vnc: 0.670 +device: 0.661 +performance: 0.653 +PID: 0.600 +KVM: 0.571 +socket: 0.547 +boot: 0.514 +files: 0.469 + +Error in user-mode calculation of ELF program's brk + +There's a discrepancy between the way QEMU user-mode and Linux calculate the initial program break for statically-linked binaries. I have a binary with the following segments: + + Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align + EXIDX 0x065a14 0x00075a14 0x00075a14 0x00588 0x00588 R 0x4 + PHDR 0x0a3000 0x000a3000 0x000a3000 0x00160 0x00160 R 0x1000 + LOAD 0x0a3000 0x000a3000 0x000a3000 0x00160 0x00160 R 0x1000 + LOAD 0x000000 0x00010000 0x00010000 0x65fa0 0x65fa0 R E 0x10000 + LOAD 0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW 0x10000 + NOTE 0x000114 0x00010114 0x00010114 0x00044 0x00044 R 0x4 + TLS 0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R 0x4 + GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x8 + GNU_RELRO 0x066b7c 0x00086b7c 0x00086b7c 0x00484 0x00484 R 0x1 + LOAD 0x07e000 0x00089000 0x00089000 0x03ff4 0x03ff4 R E 0x1000 + LOAD 0x098000 0x00030000 0x00030000 0x01000 0x01000 RW 0x1000 + +The call to set_brk in Linux's binfmt_elf.c receives these arguments: + + set_brk(0xa3160, 0xa3160, 1) + +Whereas in QEMU, info->brk gets set to 0x88f00. When the binary is run in QEMU, it crashes on the second call to brk, whereas it runs fine on real ARM hardware. I think the trouble is that the program break is set to an address lower than the virtual address of a LOAD segment (the program headers, in this case). + +I believe that this discrepancy arises because in QEMU, info->brk is only incremented when the LOAD segment in question has PROT_WRITE. For this binary, the LOAD segment with write permissions and the highest virtual address is + + LOAD 0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW 0x10000 + +which overlaps with the TLS segment: + + TLS 0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R 0x4 + +However, the Linux kernel puts the program break after the loadable segment with the highest virtual address, regardless of flags. So I think the fix is for QEMU to do the same. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/276 + + |