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 S1752741AbcDFStq (ORCPT <rfc822;w@1wt.eu>);
	Wed, 6 Apr 2016 14:49:46 -0400
Received: from mail-oi0-f46.google.com ([209.85.218.46]:35376 "EHLO
	mail-oi0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751873AbcDFSto (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 6 Apr 2016 14:49:44 -0400
MIME-Version: 1.0
In-Reply-To: <CALCETrUhLVmHtEnt-RFMdPJ3E2T_798iWvkM8ciw=pydWCWjbw@mail.gmail.com>
References: <1459960170-4454-1-git-send-email-dsafonov@virtuozzo.com>
 <1459960170-4454-2-git-send-email-dsafonov@virtuozzo.com> <CALCETrUhLVmHtEnt-RFMdPJ3E2T_798iWvkM8ciw=pydWCWjbw@mail.gmail.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Wed, 6 Apr 2016 11:49:19 -0700
Message-ID: <CALCETrX9Kxw6nw-SseaThBL4dGG3K9fYe1v4EPbYvxeE-uF4Zg@mail.gmail.com>
Subject: Re: [PATCH 1/2] x86/arch_prctl: add ARCH_SET_{COMPAT,NATIVE} to
 change compatible mode
To: Dmitry Safonov <dsafonov@virtuozzo.com>
Cc: Shuah Khan <shuahkh@osg.samsung.com>, "H. Peter Anvin" <hpa@zytor.com>,
        0x7f454c46@gmail.com, khorenko@virtuozzo.com,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Cyrill Gorcunov <gorcunov@openvz.org>, Borislav Petkov <bp@alien8.de>,
        xemul@virtuozzo.com, linux-kselftest@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>, X86 ML <x86@kernel.org>,
        Ingo Molnar <mingo@redhat.com>,
        Dave Hansen <dave.hansen@linux.intel.com>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Apr 6, 2016 at 11:04 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> [cc Dave Hansen for MPX]
>

>  - For MPX, could we track which syscall called mpx_enable_management?
>  I.e. can we stash in_compat_syscall's return from
> mpx_enable_management and use that instead of trying to determine the
> MPX data structure format by the mm's initial type?
>

Even this may be more complicated than necessary.  Could the MPX
helpers just use user_64bit_mode?  After all, if your bounds
structures don't match your bitness and you take an MPX fault, you are
screwed no matter what the kernel does, so why not just have the
kernel helpers look at the user state?

Hmm.  There's mpx_unmap_tables, too, which complicates things.

FWIW, caching the bounds directory address may not be so important.
On my Skylake laptop, reading BNDCSR using XSAVE (RFBM set to just
BNDCSR) takes about 100 cycles and reading it using XSAVEC takes about
75 cycles.

--Andy