Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752123AbdLCEGV convert rfc822-to-8bit (ORCPT <rfc822;w@1wt.eu>);
        Sat, 2 Dec 2017 23:06:21 -0500
Received: from hqemgate16.nvidia.com ([216.228.121.65]:8116 "EHLO
        hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751445AbdLCEGS (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Sat, 2 Dec 2017 23:06:18 -0500
X-PGP-Universal: processed;
        by hqpgpgate101.nvidia.com on Sat, 02 Dec 2017 20:06:18 -0800
Subject: Re: [PATCH] mmap.2: MAP_FIXED is no longer discouraged
To: Matthew Wilcox <willy@infradead.org>, Jann Horn <jannh@google.com>
CC: Michael Kerrisk <mtk.manpages@gmail.com>,
        linux-man <linux-man@vger.kernel.org>,
        Linux API <linux-api@vger.kernel.org>,
        Michael Ellerman <mpe@ellerman.id.au>, <linux-mm@kvack.org>,
        LKML <linux-kernel@vger.kernel.org>,
        linux-arch <linux-arch@vger.kernel.org>,
        Michal Hocko <mhocko@suse.com>
References: <20171202021626.26478-1-jhubbard@nvidia.com>
 <20171202150554.GA30203@bombadil.infradead.org>
 <CAG48ez2u3fjBDCMH4x3EUhG6ZD6VUa=A1p441P9fg=wUdzwHNQ@mail.gmail.com>
 <20171202221910.GA8228@bombadil.infradead.org>
X-Nvconfidentiality: public
From: John Hubbard <jhubbard@nvidia.com>
Message-ID: <d654b75e-e20b-b8ed-4564-abb1d210a921@nvidia.com>
Date: Sat, 2 Dec 2017 20:06:17 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <20171202221910.GA8228@bombadil.infradead.org>
X-Originating-IP: [10.2.168.151]
X-ClientProxiedBy: HQMAIL102.nvidia.com (172.18.146.10) To
 HQMAIL107.nvidia.com (172.20.187.13)
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2849
Lines: 66

On 12/02/2017 02:19 PM, Matthew Wilcox wrote:
> On Sat, Dec 02, 2017 at 07:49:20PM +0100, Jann Horn wrote:
>> On Sat, Dec 2, 2017 at 4:05 PM, Matthew Wilcox <willy@infradead.org> wrote:
>>> On Fri, Dec 01, 2017 at 06:16:26PM -0800, john.hubbard@gmail.com wrote:
[...]
> 
> Maybe that should be up front rather than buried at the end of the sentence.
> 
> "In a multi-threaded process, the address space can change in response to
> virtually any library call.  This is because almost any library call may be
> implemented by using dlopen(3) to load another shared library, which will be
> mapped into the process's address space.  The PAM libraries are an excellent
> example, as well as more obvious examples like brk(2), malloc(3) and even
> pthread_create(3)."
> 
> What do you think?
> 

Hi Matthew,

Here is a new version, based on your and Jann's comments. I also added a
reference to MAP_FIXED_SAFE. If it looks close, I'll send a v2 with proper
formatting applied.

I did wonder briefly if your ATM reference was a oblique commentary about
security, but then realized...you probably just needed some cash. :)

-----

This option is extremely hazardous (when used on its own) and moderately
non-portable.

On portability: a process's memory map may change significantly from one
run to the next, depending on library versions, kernel versions and ran‐
dom numbers.

On hazards: this option forcibly removes pre-existing  mappings,  making
it easy for a multi-threaded process to corrupt its own address space.

For  example,  thread  A  looks  through /proc/<pid>/maps and locates an
available address range, while thread B simultaneously acquires part  or
all  of  that  same  address range. Thread A then calls mmap(MAP_FIXED),
effectively overwriting thread B's mapping.

Thread B need not create a mapping directly;  simply  making  a  library
call that, internally, uses dlopen(3) to load some other shared library,
will suffice. The dlopen(3) call will map the library into the process's
address  space.  Furthermore, almost any library call may be implemented
using this technique.  Examples include brk(2), malloc(3),  pthread_cre‐
ate(3), and the PAM libraries (http://www.linux-pam.org).

Given the above limitations, one of the very few ways to use this option
safely is: mmap() a region, without specifying MAP_FIXED.  Then,  within
that  region,  call  mmap(MAP_FIXED) to suballocate regions. This avoids
both the portability problem (because the first mmap call lets the  ker‐
nel pick the address), and the address space corruption problem (because
the region being overwritten is already owned by the calling thread).

Newer kernels (Linux 4.16 and later) have a MAP_FIXED_SAFE  option  that
avoids  the  corruption  problem; if available, MAP_FIXED_SAFE should be
preferred over MAP_FIXED.


thanks,
John Hubbard
NVIDIA