linux-kernel - Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <13801e2a-c44d-e940-f872-890a0612a483@nvidia.com>
Date:   Thu, 12 Apr 2018 11:59:24 -0700
From:   John Hubbard <jhubbard@...dia.com>
To:     Jann Horn <jannh@...gle.com>,
        Michael Kerrisk-manpages <mtk.manpages@...il.com>
CC:     linux-man <linux-man@...r.kernel.org>,
        Michal Hocko <mhocko@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux-MM <linux-mm@...ck.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>
Subject: Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been
 reserved

On 04/12/2018 11:49 AM, Jann Horn wrote:
> On Thu, Apr 12, 2018 at 8:37 PM, Michael Kerrisk (man-pages)
> <mtk.manpages@...il.com> wrote:
>> Hi John,
>>
>> On 12 April 2018 at 20:33, John Hubbard <jhubbard@...dia.com> wrote:
>>> On 04/12/2018 08:39 AM, Jann Horn wrote:
>>>> Clarify that MAP_FIXED is appropriate if the specified address range has
>>>> been reserved using an existing mapping, but shouldn't be used otherwise.
>>>>
>>>> Signed-off-by: Jann Horn <jannh@...gle.com>
>>>> ---
>>>>  man2/mmap.2 | 19 +++++++++++--------
>>>>  1 file changed, 11 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/man2/mmap.2 b/man2/mmap.2
> [...]
>>>>  .IP
>>>>  For example, suppose that thread A looks through
>>>> @@ -284,13 +285,15 @@ and the PAM libraries
>>>>  .UR http://www.linux-pam.org
>>>>  .UE .
>>>>  .IP
>>>> -Newer kernels
>>>> -(Linux 4.17 and later) have a
>>>> +For cases in which the specified memory region has not been reserved using an
>>>> +existing mapping, newer kernels (Linux 4.17 and later) provide an option
>>>>  .B MAP_FIXED_NOREPLACE
>>>> -option that avoids the corruption problem; if available,
>>>> -.B MAP_FIXED_NOREPLACE
>>>> -should be preferred over
>>>> -.BR MAP_FIXED .
>>>> +that should be used instead; older kernels require the caller to use
>>>> +.I addr
>>>> +as a hint (without
>>>> +.BR MAP_FIXED )
>>>
>>> Here, I got lost: the sentence suddenly jumps into explaining non-MAP_FIXED
>>> behavior, in the MAP_FIXED section. Maybe if you break up the sentence, and
>>> possibly omit non-MAP_FIXED discussion, it will help.
>>
>> Hmmm -- true. That piece could be a little clearer.
> 
> How about something like this?
> 
>               For  cases in which MAP_FIXED can not be used because
> the specified memory
>               region has not been reserved using an existing mapping,
> newer kernels
>               (Linux  4.17  and  later)  provide  an  option
> MAP_FIXED_NOREPLACE  that
>               should  be  used  instead. Older kernels require the
>               caller to use addr as a hint and take appropriate action if
>               the kernel places the new mapping at a different address.
> 
> John, Michael, what do you think?


I'm still having difficulty with it, because this is in the MAP_FIXED section,
but I think you're documenting the behavior that you get if you do *not*
specify MAP_FIXED, right? Also, the hint behavior is true of both older and 
new kernels...

So, if that's your intent (you want to sort of document by contrast to what 
would happen if this option were not used), then how about something like this:


Without the MAP_FIXED option, the kernel would treat addr as a hint, rather
than a requirement, and the caller would need to take appropriate action
if the kernel placed the mapping at a different address. (For example,
munmap and try again.)


thanks,
-- 
John Hubbard
NVIDIA