[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrX9Kxw6nw-SseaThBL4dGG3K9fYe1v4EPbYvxeE-uF4Zg@mail.gmail.com>
Date: Wed, 6 Apr 2016 11:49:19 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Dmitry Safonov <dsafonov@...tuozzo.com>
Cc: Shuah Khan <shuahkh@....samsung.com>,
"H. Peter Anvin" <hpa@...or.com>, 0x7f454c46@...il.com,
khorenko@...tuozzo.com,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Cyrill Gorcunov <gorcunov@...nvz.org>,
Borislav Petkov <bp@...en8.de>, xemul@...tuozzo.com,
linux-kselftest@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
X86 ML <x86@...nel.org>, Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH 1/2] x86/arch_prctl: add ARCH_SET_{COMPAT,NATIVE} to
change compatible mode
On Wed, Apr 6, 2016 at 11:04 AM, Andy Lutomirski <luto@...capital.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
Powered by blists - more mailing lists