diff mbox series

[RFC] linux-user/mmap: Return EFAULT for invalid addresses

Message ID b71cbfb68c227ae999e8caa5e247d5bb93ddad43.camel@linuxfoundation.org
State New
Headers show
Series [RFC] linux-user/mmap: Return EFAULT for invalid addresses | expand

Commit Message

Richard Purdie Jan. 8, 2021, 5:46 p.m. UTC 
When using qemu-i386 to run gobject introspection parts of a webkitgtk 
build using musl as libc on a 64 bit host, it sits in an infinite loop 
of mremap calls of ever decreasing/increasing addresses.

I suspect something in the musl memory allocation code loops indefinitely
if it only sees ENOMEM and only exits when it hits EFAULT.

According to the docs, trying to mremap outside the address space
can/should return EFAULT and changing this allows the build to succeed.

There was previous discussion of this as it used to work before qemu 2.11
and we've carried hacks to work around it since, this appears to be a
better fix of the real issue?

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org

Comments

Richard Purdie Jan. 22, 2021, 9:37 a.m. UTC | #1 
On Fri, 2021-01-08 at 17:46 +0000, Richard Purdie wrote:
> When using qemu-i386 to run gobject introspection parts of a webkitgtk 
> build using musl as libc on a 64 bit host, it sits in an infinite loop 
> of mremap calls of ever decreasing/increasing addresses.
> 
> I suspect something in the musl memory allocation code loops indefinitely
> if it only sees ENOMEM and only exits when it hits EFAULT.
> 
> According to the docs, trying to mremap outside the address space
> can/should return EFAULT and changing this allows the build to succeed.
> 
> There was previous discussion of this as it used to work before qemu 2.11
> and we've carried hacks to work around it since, this appears to be a
> better fix of the real issue?
> 
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org
> 
> Index: qemu-5.2.0/linux-user/mmap.c
> ===================================================================
> --- qemu-5.2.0.orig/linux-user/mmap.c
> +++ qemu-5.2.0/linux-user/mmap.c
> @@ -727,7 +727,7 @@ abi_long target_mremap(abi_ulong old_add
>           !guest_range_valid(new_addr, new_size)) ||
>          ((flags & MREMAP_MAYMOVE) == 0 &&
>           !guest_range_valid(old_addr, new_size))) {
> -        errno = ENOMEM;
> +        errno = EFAULT;
>          return -1;
>      }

Any comments on this? I believe its a valid issue that needs fixing and
multiple distros appear to be carrying fixes in this area related to
this.

Cheers,

Richard
Philippe Mathieu-Daudé Jan. 22, 2021, 10:28 a.m. UTC | #2 
Cc'ing maintainer

On 1/22/21 10:37 AM, Richard Purdie wrote:
> On Fri, 2021-01-08 at 17:46 +0000, Richard Purdie wrote:
>> When using qemu-i386 to run gobject introspection parts of a webkitgtk 
>> build using musl as libc on a 64 bit host, it sits in an infinite loop 
>> of mremap calls of ever decreasing/increasing addresses.
>>
>> I suspect something in the musl memory allocation code loops indefinitely
>> if it only sees ENOMEM and only exits when it hits EFAULT.
>>
>> According to the docs, trying to mremap outside the address space
>> can/should return EFAULT and changing this allows the build to succeed.
>>
>> There was previous discussion of this as it used to work before qemu 2.11
>> and we've carried hacks to work around it since, this appears to be a
>> better fix of the real issue?
>>
>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org
>>
>> Index: qemu-5.2.0/linux-user/mmap.c
>> ===================================================================
>> --- qemu-5.2.0.orig/linux-user/mmap.c
>> +++ qemu-5.2.0/linux-user/mmap.c
>> @@ -727,7 +727,7 @@ abi_long target_mremap(abi_ulong old_add
>>           !guest_range_valid(new_addr, new_size)) ||
>>          ((flags & MREMAP_MAYMOVE) == 0 &&
>>           !guest_range_valid(old_addr, new_size))) {
>> -        errno = ENOMEM;
>> +        errno = EFAULT;
>>          return -1;
>>      }
> 
> Any comments on this? I believe its a valid issue that needs fixing and
> multiple distros appear to be carrying fixes in this area related to
> this.
> 
> Cheers,
> 
> Richard
> 
>
Laurent Vivier Feb. 13, 2021, 5:40 p.m. UTC | #3 
Le 08/01/2021 à 18:46, Richard Purdie a écrit :
> When using qemu-i386 to run gobject introspection parts of a webkitgtk 
> build using musl as libc on a 64 bit host, it sits in an infinite loop 
> of mremap calls of ever decreasing/increasing addresses.
> 
> I suspect something in the musl memory allocation code loops indefinitely
> if it only sees ENOMEM and only exits when it hits EFAULT.
> 
> According to the docs, trying to mremap outside the address space
> can/should return EFAULT and changing this allows the build to succeed.
> 
> There was previous discussion of this as it used to work before qemu 2.11
> and we've carried hacks to work around it since, this appears to be a
> better fix of the real issue?
> 
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org
> 
> Index: qemu-5.2.0/linux-user/mmap.c
> ===================================================================
> --- qemu-5.2.0.orig/linux-user/mmap.c
> +++ qemu-5.2.0/linux-user/mmap.c
> @@ -727,7 +727,7 @@ abi_long target_mremap(abi_ulong old_add
>           !guest_range_valid(new_addr, new_size)) ||
>          ((flags & MREMAP_MAYMOVE) == 0 &&
>           !guest_range_valid(old_addr, new_size))) {
> -        errno = ENOMEM;
> +        errno = EFAULT;
>          return -1;
>      }
>  
> 
> 

I agree with that, the ENOMEM is returned when there is not enough virtual memory (the
mmap_find_vma() case).

According to the manpage, EFAULT is returned when old_addr and old_addr + old_size is an invalid
address space.

So:

    if (!guest_range_valid(old_addr, old_size)) {
        errno = EFAULT;
        return -1;
    }

But in the case of new_size and new_addr, it seems the good value to use is EINVAL.

So:

   if (((flags & MREMAP_FIXED) && !guest_range_valid(new_addr, new_size)) ||
       ((flags & MREMAP_MAYMOVE) == 0 && !guest_range_valid(old_addr, new_size))) {
        errno = EINVAL;
        return -1;
    }

Did you try that?

Thanks,
Laurent
Richard Purdie Feb. 16, 2021, 11:49 a.m. UTC | #4 
On Sat, 2021-02-13 at 18:40 +0100, Laurent Vivier wrote:
> Le 08/01/2021 à 18:46, Richard Purdie a écrit :
> > When using qemu-i386 to run gobject introspection parts of a webkitgtk 
> > build using musl as libc on a 64 bit host, it sits in an infinite loop 
> > of mremap calls of ever decreasing/increasing addresses.
> > 
> > I suspect something in the musl memory allocation code loops indefinitely
> > if it only sees ENOMEM and only exits when it hits EFAULT.
> > 
> > According to the docs, trying to mremap outside the address space
> > can/should return EFAULT and changing this allows the build to succeed.
> > 
> > There was previous discussion of this as it used to work before qemu 2.11
> > and we've carried hacks to work around it since, this appears to be a
> > better fix of the real issue?
> > 
> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org
> > 
> > Index: qemu-5.2.0/linux-user/mmap.c
> > ===================================================================
> > --- qemu-5.2.0.orig/linux-user/mmap.c
> > +++ qemu-5.2.0/linux-user/mmap.c
> > @@ -727,7 +727,7 @@ abi_long target_mremap(abi_ulong old_add
> >           !guest_range_valid(new_addr, new_size)) ||
> >          ((flags & MREMAP_MAYMOVE) == 0 &&
> >           !guest_range_valid(old_addr, new_size))) {
> > -        errno = ENOMEM;
> > +        errno = EFAULT;
> >          return -1;
> >      }
> >  
> > 
> > 
> > 
> 
> I agree with that, the ENOMEM is returned when there is not enough virtual memory (the
> mmap_find_vma() case).
> 
> According to the manpage, EFAULT is returned when old_addr and old_addr + old_size is an invalid
> address space.
> 
> So:
> 
>     if (!guest_range_valid(old_addr, old_size)) {
>         errno = EFAULT;
>         return -1;
>     }
> 
> But in the case of new_size and new_addr, it seems the good value to use is EINVAL.
> 
> So:
> 
>    if (((flags & MREMAP_FIXED) && !guest_range_valid(new_addr, new_size)) ||
>        ((flags & MREMAP_MAYMOVE) == 0 && !guest_range_valid(old_addr, new_size))) {
>         errno = EINVAL;
>         return -1;
>     }
> 
> Did you try that?

Its taken me a short while to reproduce the test environment but I did
so and can confirm that using EINVAL works just as well as EFAULT in
the test case we have. The above would therefore seem to make sense to
me and would fix the case we found.

Cheers,

Richard
Laurent Vivier Feb. 16, 2021, 4:21 p.m. UTC | #5 
Le 16/02/2021 à 12:49, Richard Purdie a écrit :
> On Sat, 2021-02-13 at 18:40 +0100, Laurent Vivier wrote:
>> Le 08/01/2021 à 18:46, Richard Purdie a écrit :
>>> When using qemu-i386 to run gobject introspection parts of a webkitgtk 
>>> build using musl as libc on a 64 bit host, it sits in an infinite loop 
>>> of mremap calls of ever decreasing/increasing addresses.
>>>
>>> I suspect something in the musl memory allocation code loops indefinitely
>>> if it only sees ENOMEM and only exits when it hits EFAULT.
>>>
>>> According to the docs, trying to mremap outside the address space
>>> can/should return EFAULT and changing this allows the build to succeed.
>>>
>>> There was previous discussion of this as it used to work before qemu 2.11
>>> and we've carried hacks to work around it since, this appears to be a
>>> better fix of the real issue?
>>>
>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org
>>>
>>> Index: qemu-5.2.0/linux-user/mmap.c
>>> ===================================================================
>>> --- qemu-5.2.0.orig/linux-user/mmap.c
>>> +++ qemu-5.2.0/linux-user/mmap.c
>>> @@ -727,7 +727,7 @@ abi_long target_mremap(abi_ulong old_add
>>>           !guest_range_valid(new_addr, new_size)) ||
>>>          ((flags & MREMAP_MAYMOVE) == 0 &&
>>>           !guest_range_valid(old_addr, new_size))) {
>>> -        errno = ENOMEM;
>>> +        errno = EFAULT;
>>>          return -1;
>>>      }
>>>  
>>>
>>>
>>>
>>
>> I agree with that, the ENOMEM is returned when there is not enough virtual memory (the
>> mmap_find_vma() case).
>>
>> According to the manpage, EFAULT is returned when old_addr and old_addr + old_size is an invalid
>> address space.
>>
>> So:
>>
>>     if (!guest_range_valid(old_addr, old_size)) {
>>         errno = EFAULT;
>>         return -1;
>>     }
>>
>> But in the case of new_size and new_addr, it seems the good value to use is EINVAL.
>>
>> So:
>>
>>    if (((flags & MREMAP_FIXED) && !guest_range_valid(new_addr, new_size)) ||
>>        ((flags & MREMAP_MAYMOVE) == 0 && !guest_range_valid(old_addr, new_size))) {
>>         errno = EINVAL;
>>         return -1;
>>     }
>>
>> Did you try that?
> 
> Its taken me a short while to reproduce the test environment but I did
> so and can confirm that using EINVAL works just as well as EFAULT in
> the test case we have. The above would therefore seem to make sense to
> me and would fix the case we found.

Could you send a v2 of your patch with these changes?

Thanks,
Laurent
diff mbox series

Patch

Index: qemu-5.2.0/linux-user/mmap.c
===================================================================
--- qemu-5.2.0.orig/linux-user/mmap.c
+++ qemu-5.2.0/linux-user/mmap.c
@@ -727,7 +727,7 @@  abi_long target_mremap(abi_ulong old_add
          !guest_range_valid(new_addr, new_size)) ||
         ((flags & MREMAP_MAYMOVE) == 0 &&
          !guest_range_valid(old_addr, new_size))) {
-        errno = ENOMEM;
+        errno = EFAULT;
         return -1;
     }