linux-kernel - Re: Question about mmap syscall and POSIX standard on mips arch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20181018230909.nze5ws5ro2r3kvw6@pburton-laptop>
Date:   Thu, 18 Oct 2018 23:09:11 +0000
From:   Paul Burton <paul.burton@...s.com>
To:     Al Viro <viro@...IV.linux.org.uk>
CC:     "Hongzhi, Song" <hongzhi.song@...driver.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "mm-commits@...r.kernel.org" <mm-commits@...r.kernel.org>,
        "linux-mips@...ux-mips.org" <linux-mips@...ux-mips.org>,
        Ralf Baechle <ralf@...ux-mips.org>
Subject: Re: Question about mmap syscall and POSIX standard on mips arch

Hi Al,

On Thu, Oct 18, 2018 at 05:32:00AM +0100, Al Viro wrote:
> [mips folks Cc'd]
> 
> On Thu, Oct 18, 2018 at 11:26:02AM +0800, Hongzhi, Song wrote:
> > Hi all,
> > 
> > Ltp has a POSIX teatcase about mmap, 24-2.c.
> > 
> > https://github.com/linux-test-project/ltp/blob/e816127e5d8efbff5ae53e9c2292fae22f36838b/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-2.c#L94
> 
> [basically, MAP_FIXED mmap with addr + len > TASK_SIZE fails with
> -EINVAL on mips and -ENOMEM elsewhere]
>  
> > Under POSIX standard, the expected errno should be ENOMEM
> > 
> > when the specific [addr+len] exceeds the bound of memory.
> 
> The mmap() function may fail if:
> 
> [EINVAL]
> The addr argument (if MAP_FIXED was specified) or off is not a multiple
> of the page size as returned by sysconf(), or is considered invalid by
>                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> the implementation.
> ^^^^^^^^^^^^^^^^^^^
> 
> So that behaviour gets past POSIX.  That part is mostly about the
> things like cache aliasing constraints, etc., but it leaves enough
> space to weasel out.  Said that, this
> 
> [ENOMEM]
> MAP_FIXED was specified, and the range [addr,addr+len) exceeds that allowed
> for the address space of a process; or, if MAP_FIXED was not specified and
> there is insufficient room in the address space to effect the mapping.
> 
> is a lot more specific, so switching to -ENOMEM there might be a good idea,
> especially since on other architectures we do get -ENOMEM in that case,
> AFAICS.

Thanks for the heads up - that does sound like reasonably clear
non-compliance. I'll make a note to put together a patch & test it out,
likely next week, if nobody submits one first.

Thanks,
    Paul