qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] linux-user: mremap fails with EFAULT if address range overla


From: Tobias Koch
Subject: Re: [PATCH] linux-user: mremap fails with EFAULT if address range overlaps with stack guard
Date: Mon, 15 Jun 2020 23:28:02 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

Hm, I see I need to have another look at this :)

On 6/15/20 10:17 AM, Tobias Koch wrote:
> Hi Laurent,
>
> the code in musl libc probing the stack is in
>
>     https://git.musl-libc.org/cgit/musl/plain/src/thread/pthread_getattr_np.c
>
> The setup in elfload.c does work, but only when reserved_va is not set. In 
> that case, any stack guard violation is
> handled by the host kernel and thus results in the expected EFAULT.
>
> However, in case of e.g. a 32bit target being emulated on a 64bit host, 
> reserved_va is set and the current code in
> mmap.c will only produce a more generic ENOMEM, deviating from the kernel's 
> behavior.
>
>
> On 5/7/20 5:35 PM, Laurent Vivier wrote:
>> Le 05/03/2020 à 22:05, Tobias Koch a écrit :
>>> If the address range starting at old_address overlaps with the stack guard 
>>> it
>>> is invalid and mremap must fail with EFAULT. The musl c library relies on 
>>> this
>>> behavior to detect the stack size, which it does by doing consecutive 
>>> mremaps
>>> until it hits the stack guard. Without this patch, software (such as the 
>>> Ruby
>>> interpreter) that calls pthread_getattr_np under musl will crash on 32 bit
>>> targets emulated on a 64 bit host.
>> Could you share some pointers to the code that is doing this?
>>
>> We have already this kind of code in linux-user/elfload.c,
>> setup_arg_pages(): could you check why it doesn't work?
>>
>> Thanks,
>> Laurent



reply via email to

[Prev in Thread] Current Thread [Next in Thread]