[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 12 Dec 2014 09:31:34 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Dave Hansen <dave.hansen@...ux.intel.com>
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
* Dave Hansen <dave.hansen@...ux.intel.com> wrote:
> +config X86_INTEL_MPX
> + prompt "Intel MPX (Memory Protection Extensions)"
> + def_bool y
> + depends on CPU_SUP_INTEL
> + ---help---
> + MPX provides hardware features that can be used in
> + conjunction with compiler-instrumented code to check
> + memory references. It is designed to detect buffer
> + overflow or underflow bugs.
> +
> + This option enables running applications which are
> + instrumented or otherwise use MPX. It does not use MPX
> + itself inside the kernel or to protect the kernel
> + against bad memory references.
> +
> + Enabling this option will make the kernel larger:
> + ~8k of kernel text and 36 bytes of data on a 64-bit
> + defconfig. It adds a long to the 'mm_struct' which
> + will increase the kernel memory overhead of each
> + process and adds some branches to paths used during
> + exec() and munmap().
> +
> + If unsure, say Y.
That description looks pretty good to me.
Linus, what's your take on the default-y? To me it seems there's
arguments both ways: usually we allow unprivileged ABIs to be
disabled only under EXPERT and make them default-y (to help
adaption and to define what the default ABI of 'Linux' is - we
did a default-y for SECCOMP for example) - OTOH this is a new
ABI, the processors aren't even out yet, and there's costs to the
MM code even in the non-MPX case, so it's not as clear-cut as in
the SECCOMP case which had essentially zero runtime cost.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists