Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170621004107.GZ1627@brightrain.aerifal.cx>
Date: Tue, 20 Jun 2017 20:41:07 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: pthread_getattr_np doing loads of mremaps on ARM, MIPS
 under QEMU user-mode

On Thu, Jun 15, 2017 at 11:01:48PM +0300, Tobias Koch wrote:
> >This is not particularly unusual (it's the best way we could find
> >to measure the initial thread's stack size), but it's possible
> >that qemu user mode is botching emulation of mremap and thus
> >resulting in a wrong stack size being reported. Can you send a
> >full strace (qemu-arm -strace, maybe also real strace of the qemu
> >process with the host strace utility) log of the crash? That will
> >probably shed some light on what's happening.
> attached recorded via
> 
> strace -o host-strace-qemu.log /usr/bin/qemu-arm-static -strace
> /usr/bin/ruby2.4 > qemu-strace-ruby.log 2>&1
> 
> [...]
> 
> 13641 set_tid_address(-159391760,-159706348,1,-159391412,-159391788,-150995520) = 13641
> 13641 open("/usr/etc/ld-musl-arm.path",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory)
> 13641 open("/usr/lib/libruby-2.4.so.2.4",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
> 13641 fcntl64(3,F_SETFD,1) = 0
> 13641 fstat64(3,0xf6fff860) = 0
> 13641 read(3,0xf6fff460,936) = 936
> 13641 mmap2(NULL,2342912,PROT_EXEC|PROT_READ,MAP_PRIVATE,3,0) = 0xf650d000
> 13641 mmap2(0xf673e000,45056,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0x221) = 0xf673e000
> 13641 mmap2(0xf6743000,24576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0xf6743000
> 13641 close(3) = 0
> 13641 open("/usr/lib/libgmp.so.10",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
> 13641 fcntl64(3,F_SETFD,1) = 0
> 13641 fstat64(3,0xf6fff860) = 0
> 13641 read(3,0xf6fff460,936) = 936
> 13641 mmap2(NULL,462848,PROT_EXEC|PROT_READ,MAP_PRIVATE,3,0) = 0xf649c000
> 13641 mmap2(0xf650b000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0x5f) = 0xf650b000
> 13641 close(3) = 0
> 13641 mprotect(0xf673e000,12288,PROT_READ) = 0
> 13641 mprotect(0xf650b000,4096,PROT_READ) = 0
> 13641 mprotect(0xf67fb000,4096,PROT_READ) = 0
> 13641 mprotect(0x00020000,4096,PROT_READ) = 0
> 13641 fstat64(0,0xf6fffd08) = 0
> 13641 fstat64(1,0xf6fffd08) = 0
> 13641 fstat64(2,0xf6fffd08) = 0
> 13641 mremap(-151003136,4096,8192,0,0,-159391424) = -1 errno=12 (Cannot allocate memory)
> 13641 mremap(-151007232,4096,8192,0,0,-159391424) = -1 errno=12 (Cannot allocate memory)
> 13641 mremap(-151011328,4096,8192,0,0,-159391424) = -1 errno=12 (Cannot allocate memory)
> .
> .
> .
> 13641 mremap(4096,4096,8192,0,0,-159391424) = -1 errno=12 (Cannot allocate memory)
> 13641 mremap(0,4096,8192,0,0,-159391424) = -1 errno=12 (Cannot allocate memory)
> 13641 mremap(-4096,4096,8192,0,0,-159391424) = -1 errno=14 (Bad address)

OK, qemu-user is just emulating mremap very poorly. The man page
documents that it fails with EFAULT when the address passed is not
valid, but qemu seems to be giving ENOMEM, which has a different
meaning. I remember we looked hard when this was first implemented to
find an acceptable/safe way to probe for valid pages, so I doubt we'll
find a better or equally good way that both works around the bug in
qemu-user and does the right thing on all real kernels. I think the
qemu bug should just be reported and fixed.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.