Re: [PATCH] linux-user: mremap fails with EFAULT if address range overlaps with stack guard

[Tobias Koch]

Ok, so according to the manpage, mremap generates EFAULT when "the range 
old_address to old_address+old_size is an
invalid virtual memory address for this process". This is what the kernel does 
for the stack guard. However, the
mappings in setup_arg_pages() will only ever provoke an ENOMEM, because there 
is no artifical way to turn a page into an
invalid address. So as long as target bits >= host bits, this works as expected 
and EFAULT is generated, because then
mremap is basically passed through and the kernel responds directly. But when 
reserved_va is set, this needs to be
special-cased to fake kernel behavior.

I'm open to other suggestions. I also understand that the code duplication in 
elfload.c and mmap.c to handle this is
undesirable, but the most viable alternative seems to be introducing more 
globals.

On 6/15/20 11:28 PM, Tobias Koch wrote:
> 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?