Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752721AbaAZITR (ORCPT ); Sun, 26 Jan 2014 03:19:17 -0500 Received: from mail-ee0-f46.google.com ([74.125.83.46]:51548 "EHLO mail-ee0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751456AbaAZITQ (ORCPT ); Sun, 26 Jan 2014 03:19:16 -0500 Date: Sun, 26 Jan 2014 09:19:12 +0100 From: Ingo Molnar To: Qiaowei Ren Cc: "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 0/4] Intel MPX support Message-ID: <20140126081912.GA28831@gmail.com> References: <1390727338-20487-1-git-send-email-qiaowei.ren@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1390727338-20487-1-git-send-email-qiaowei.ren@intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Qiaowei Ren wrote: > This patchset adds support for the Memory Protection Extensions > (MPX) feature found in future Intel processors. > > MPX can be used in conjunction with compiler changes to check memory > references, for those references whose compile-time normal intentions > are usurped at runtime due to buffer overflow or underflow. > > MPX provides this capability at very low performance overhead for > newly compiled code, and provides compatibility mechanisms with legacy > software components. MPX architecture is designed allow a machine to > run both MPX enabled software and legacy software that is MPX unaware. > In such a case, the legacy software does not benefit from MPX, but it > also does not experience any change in functionality or reduction in > performance. > > More information about Intel MPX can be found in "Intel(R) Architecture > Instruction Set Extensions Programming Reference". > > To get the advantage of MPX, changes are required in the OS kernel, > binutils, compiler, system libraries support. > > New GCC option -fmpx is introduced to utilize MPX instructions. > Currently GCC compiler sources with MPX support is available in a > separate branch in common GCC SVN repository. See GCC SVN page > (http://gcc.gnu.org/svn.html) for details. > > To have the full protection, we had to add MPX instrumentation to all > the necessary Glibc routines (e.g. memcpy) written on assembler, and > compile Glibc with the MPX enabled GCC compiler. Currently MPX enabled > Glibc source can be found in Glibc git repository. > > Enabling an application to use MPX will generally not require source > code updates but there is some runtime code, which is responsible for > configuring and enabling MPX, needed in order to make use of MPX. > For most applications this runtime support will be available by linking > to a library supplied by the compiler or possibly it will come directly > from the OS once OS versions that support MPX are available. > > MPX kernel code, namely this patchset, has mainly the 2 responsibilities: > provide handlers for bounds faults (#BR), and manage bounds memory. AFAICS the kernel side implementation causes no runtime overhead for non-MPX workloads, and also causes no runtime overhead for non-MPX hardware, right? > Currently no hardware with MPX ISA is available but it is always > possible to use SDE (Intel(R) software Development Emulator) instead, > which can be downloaded from > http://software.intel.com/en-us/articles/intel-software-development-emulator > > > Changes since v1: > * check to see if #BR occurred in userspace or kernel space. > * use generic structure and macro as much as possible when > decode mpx instructions. > > Changes since v2: > * fix some compile warnings. > * update documentation. > > Qiaowei Ren (4): > x86, mpx: add documentation on Intel MPX > x86, mpx: hook #BR exception handler to allocate bound tables > x86, mpx: add prctl commands PR_MPX_INIT, PR_MPX_RELEASE > x86, mpx: extend siginfo structure to include bound violation > information > > Documentation/x86/intel_mpx.txt | 226 ++++++++++++++++++++ > arch/x86/Kconfig | 4 + > arch/x86/include/asm/mpx.h | 63 ++++++ > arch/x86/include/asm/processor.h | 16 ++ > arch/x86/kernel/Makefile | 1 + > arch/x86/kernel/mpx.c | 415 ++++++++++++++++++++++++++++++++++++ > arch/x86/kernel/traps.c | 61 +++++- > include/uapi/asm-generic/siginfo.h | 9 +- > include/uapi/linux/prctl.h | 6 + > kernel/signal.c | 4 + > kernel/sys.c | 12 + > 11 files changed, 815 insertions(+), 2 deletions(-) > create mode 100644 Documentation/x86/intel_mpx.txt > create mode 100644 arch/x86/include/asm/mpx.h > create mode 100644 arch/x86/kernel/mpx.c Ok, this summary was pretty good - it addresses my prior objections wrt. submission quality. Once the details are fleshed out this sure looks like a useful feature. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/