From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1032055AbdAEXSR (ORCPT <rfc822;w@1wt.eu>);
        Thu, 5 Jan 2017 18:18:17 -0500
Received: from mga09.intel.com ([134.134.136.24]:33688 "EHLO mga09.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1761718AbdAEXSI (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 5 Jan 2017 18:18:08 -0500
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.33,322,1477983600"; 
   d="scan'208";a="46133398"
Subject: Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR
To: Andy Lutomirski <luto@amacapital.net>
References: <20161227015413.187403-1-kirill.shutemov@linux.intel.com>
 <20161227015413.187403-30-kirill.shutemov@linux.intel.com>
 <5a3dcc25-b264-37c7-c090-09981b23940d@intel.com>
 <20170105192910.q26ozg4ci4i3j2ai@black.fi.intel.com>
 <161ece66-fbf4-cb89-3da6-91b4851af69f@intel.com>
 <CALCETrUQ2+P424d9MW-Dy2yQ0+EnMfBuY80wd8NkNmc8is0AUw@mail.gmail.com>
 <978d5f1a-ec4d-f747-93fd-27ecfe10cb88@intel.com>
 <CALCETrW7yxmgrR15yvxkXOF1pHy5vicwDv6Oj019ecEyBCrWBQ@mail.gmail.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Andrew Morton <akpm@linux-foundation.org>, X86 ML <x86@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
        Arnd Bergmann <arnd@arndb.de>, "H. Peter Anvin" <hpa@zytor.com>,
        Andi Kleen <ak@linux.intel.com>,
        linux-arch <linux-arch@vger.kernel.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Linux API <linux-api@vger.kernel.org>
From: Dave Hansen <dave.hansen@intel.com>
Message-ID: <215875b1-2035-df2a-99b2-1b1b036e2a3c@intel.com>
Date: Thu, 5 Jan 2017 15:17:22 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <CALCETrW7yxmgrR15yvxkXOF1pHy5vicwDv6Oj019ecEyBCrWBQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 01/05/2017 01:27 PM, Andy Lutomirski wrote:
> On Thu, Jan 5, 2017 at 12:49 PM, Dave Hansen <dave.hansen@intel.com> wrote:
...
>> Remember, we already have (legacy MPX) binaries in the wild that have no
>> knowledge of this stuff.  So, we can implicitly have the kernel bump
>> this rlimit around, but we can't expect userspace to do it, ever.
> 
> If you s/rlimit/prctl, then I think this all makes sense with one
> exception.  It would be a bit sad if the personality-setting tool
> didn't work if compiled with MPX.

Ahh, because if you have MPX enabled you *can't* sanely switch between
the two modes because you suddenly go from having small bounds tables to
having big ones?

It's not the simplest thing in the world to do, but there's nothing
keeping the personality-setting tool from doing all the work.  It can do:

	new_bd = malloc(1TB);
	prctl(MPX_DISABLE_MANAGEMENT);
	memcpy(new_bd, old_bd, LEGACY_MPX_BD_SIZE);
	set_bounds_config(new_bd | ENABLE_BIT);
	prctl(WIDER_VADDR_WIDTH);
	prctl(MPX_ENABLE_MANAGEMENT);
	

> So what if we had a second prctl field that is the value that kicks in
> after execve()?

Yeah, that's a pretty sane way to do it too.  execve() is a nice chokepoint.