linux-kernel - Re: [GIT pull] x86 mpx support for 3.19

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <548A147E.1020507@linux.intel.com>
Date:	Thu, 11 Dec 2014 14:02:38 -0800
From:	Dave Hansen <dave.hansen@...ux.intel.com>
To:	Ingo Molnar <mingo@...nel.org>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	the arch/x86 maintainers <x86@...nel.org>
Subject: Re: [GIT pull] x86 mpx support for 3.19

On 12/10/2014 10:19 PM, Ingo Molnar wrote:
> * Dave Hansen <dave.hansen@...ux.intel.com> wrote:
>> @@ -1575,6 +1571,27 @@ config X86_SMAP
>>  
>>  	  If unsure, say Y.
>>  
>> +config X86_INTEL_MPX
>> +	prompt "Intel MPX (Memory Protection Extensions)" if EXPERT
> 
> I think the 'if EXPERT' needs to be dropped.

Fine with me.

>> +	def_bool y
>> +	depends on CPU_SUP_INTEL
> 
> On the one hand, the 'def_bool y' might be acceptable, if we 
> think of MPX as X32 or SECCOMP: ABI extensions that are only 
> really useful if all distros enable it.

It's a _bit_ different than X32 or SECCOMP, though.  An x32 app is a
doorstop if the kernel's config option is off.  An MPX-instrumented app
ends up looking like a dumb app running a bunch of noops (for the MPX
instructions and prefixes) and being mean to the icache, but it's not a
doorstop.

That said, we *really* want distros enabling it.  (Putting my Intel hat
on firmly now...)  MPX already requires recompiling binaries, which is a
fairly large burden.  If an application writer goes to that trouble, we
really want to make sure that the kernel support is there.

It'd be a real shame to have an app compiled with MPX support (and all
those noops and their overhead), running on a CPU with silicon that
supports MPX, and a kernel that *can* support MPX... and then not use it.

>> +	  Enabling this option will make the kernel larger and
>> +	  slightly increase the size of some kernel data
>> +	  structures.
> 
> And will add a few branches to critical code paths, right?

Yep, new patch attached.

View attachment "x86-mpx-real-config-option-v3.patch" of type "text/x-patch" (1860 bytes)