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

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

[Richard Purdie]

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;
     }
 

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

[Richard Purdie]

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

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

[Philippe Mathieu-Daudé]

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
> 
> 

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

[Laurent Vivier]

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

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

[Richard Purdie]

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

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

[Laurent Vivier]

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

[PATCH v2] linux-user/mmap: Return EFAULT/EINVAL for invalid addresses

[Richard Purdie]

When using qemu-i386 to build qemux86 webkitgtk on musl, 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 other
errors such as EFAULT or EINVAL.

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

A better return value for the other cases of invalid addresses is
EINVAL rather than ENOMEM so adjust the other part of the test to this.

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
@@ -722,12 +722,14 @@ abi_long target_mremap(abi_ulong old_add
     int prot;
     void *host_addr;
 
-    if (!guest_range_valid(old_addr, old_size) ||
-        ((flags & MREMAP_FIXED) &&
-         !guest_range_valid(new_addr, new_size)) ||
-        ((flags & MREMAP_MAYMOVE) == 0 &&
-         !guest_range_valid(old_addr, new_size))) {
-        errno = ENOMEM;
+    if (!guest_range_valid(old_addr, old_size)) {
+        errno = EFAULT;
+        return -1;
+    }
+
+    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;
     }
 

Re: [PATCH v2] linux-user/mmap: Return EFAULT/EINVAL for invalid addresses

[Laurent Vivier]

Le 16/02/2021 à 20:01, Richard Purdie a écrit :
> When using qemu-i386 to build qemux86 webkitgtk on musl, 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 other
> errors such as EFAULT or EINVAL.
> 
> According to the docs, trying to mremap outside the address space
> can/should return EFAULT and changing this allows the build to succeed.
> 
> A better return value for the other cases of invalid addresses is
> EINVAL rather than ENOMEM so adjust the other part of the test to this.
> 
> 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
> @@ -722,12 +722,14 @@ abi_long target_mremap(abi_ulong old_add
>      int prot;
>      void *host_addr;
>  
> -    if (!guest_range_valid(old_addr, old_size) ||
> -        ((flags & MREMAP_FIXED) &&
> -         !guest_range_valid(new_addr, new_size)) ||
> -        ((flags & MREMAP_MAYMOVE) == 0 &&
> -         !guest_range_valid(old_addr, new_size))) {
> -        errno = ENOMEM;
> +    if (!guest_range_valid(old_addr, old_size)) {
> +        errno = EFAULT;
> +        return -1;
> +    }
> +
> +    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;
>      }
>  
> 
> 

Reviewed-by: Laurent Vivier <laurent@vivier.eu>