[PATCH 0/5] x86: finish the MPX removal process

[PATCH 0/5] x86: finish the MPX removal process

[Dave Hansen]

MPX requires recompiling applications, which requires compiler support.
Unfortunately, GCC 9.1 is expected to be be released without support for
MPX.  This means that there was only a relatively small window where
folks could have ever used MPX.  It failed to gain wide adoption in the
industry, and Linux was the only mainstream OS to ever support it widely.

Support for the feature may also disappear on future processors.

This set completes the process that we started during the 5.4 merge window.

I'd _rather_ this go in via the x86 tree, but I'm not picky.  I could also
send a pull request directly to Linus.  This series is also available here
(mostly for 0day to chew on):

	https://git.kernel.org/pub/scm/linux/kernel/git/daveh/x86-mpx.git/log/?h=mpx-remove-20200123

This posting is mostly an FYI in case any affected maintainers have any
concerns.

 Documentation/x86/intel_mpx.rst            |  252 -------
 arch/x86/include/asm/mpx.h                 |  116 ---
 arch/x86/include/asm/trace/mpx.h           |  134 ----
 arch/x86/mm/mpx.c                          |  938 -----------------------------
 b/arch/powerpc/include/asm/mmu_context.h   |    5 
 b/arch/um/include/asm/mmu_context.h        |    5 
 b/arch/unicore32/include/asm/mmu_context.h |    5 
 b/arch/x86/Kconfig                         |   28 
 b/arch/x86/include/asm/bugs.h              |    6 
 b/arch/x86/include/asm/disabled-features.h |    8 
 b/arch/x86/include/asm/mmu.h               |    4 
 b/arch/x86/include/asm/mmu_context.h       |   26 
 b/arch/x86/include/asm/processor.h         |   18 
 b/arch/x86/kernel/alternative.c            |    1 
 b/arch/x86/kernel/cpu/common.c             |   18 
 b/arch/x86/kernel/cpu/intel.c              |   36 -
 b/arch/x86/kernel/setup.c                  |    2 
 b/arch/x86/kernel/sys_x86_64.c             |    9 
 b/arch/x86/kernel/traps.c                  |   74 --
 b/arch/x86/mm/Makefile                     |    1 
 b/arch/x86/mm/hugetlbpage.c                |    5 
 b/arch/x86/mm/mmap.c                       |    2 
 b/fs/exec.c                                |    1 
 b/include/asm-generic/mm_hooks.h           |    5 
 24 files changed, 2 insertions(+), 1697 deletions(-)

Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: x86@kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-arch@vger.kernel.org
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Cc: Guan Xuetao <gxt@pku.edu.cn>

[PATCH 4/5] mm: remove arch_bprm_mm_init() hook

[Dave Hansen]

From: Dave Hansen <dave.hansen@linux.intel.com>

MPX is being removed from the kernel due to a lack of support
in the toolchain going forward (gcc).

arch_bprm_mm_init() is used at execve() time.  The only non-stub
implementation is on x86 for MPX.  Remove the hook entirely from
all architectures and generic code.

Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: x86@kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-arch@vger.kernel.org
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Cc: Guan Xuetao <gxt@pku.edu.cn>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
---

 b/arch/powerpc/include/asm/mmu_context.h   |    5 -----
 b/arch/um/include/asm/mmu_context.h        |    5 -----
 b/arch/unicore32/include/asm/mmu_context.h |    5 -----
 b/arch/x86/include/asm/mmu_context.h       |    6 ------
 b/fs/exec.c                                |    1 -
 b/include/asm-generic/mm_hooks.h           |    5 -----
 6 files changed, 27 deletions(-)

diff -puN arch/powerpc/include/asm/mmu_context.h~mpx-remove-generic-mm arch/powerpc/include/asm/mmu_context.h
--- a/arch/powerpc/include/asm/mmu_context.h~mpx-remove-generic-mm	2020-01-23 10:41:07.054942434 -0800
+++ b/arch/powerpc/include/asm/mmu_context.h	2020-01-23 10:41:07.068942434 -0800
@@ -238,11 +238,6 @@ static inline void arch_unmap(struct mm_
 		mm->context.vdso_base = 0;
 }
 
-static inline void arch_bprm_mm_init(struct mm_struct *mm,
-				     struct vm_area_struct *vma)
-{
-}
-
 #ifdef CONFIG_PPC_MEM_KEYS
 bool arch_vma_access_permitted(struct vm_area_struct *vma, bool write,
 			       bool execute, bool foreign);
diff -puN arch/um/include/asm/mmu_context.h~mpx-remove-generic-mm arch/um/include/asm/mmu_context.h
--- a/arch/um/include/asm/mmu_context.h~mpx-remove-generic-mm	2020-01-23 10:41:07.056942434 -0800
+++ b/arch/um/include/asm/mmu_context.h	2020-01-23 10:41:07.068942434 -0800
@@ -25,11 +25,6 @@ static inline void arch_unmap(struct mm_
 			unsigned long start, unsigned long end)
 {
 }
-static inline void arch_bprm_mm_init(struct mm_struct *mm,
-				     struct vm_area_struct *vma)
-{
-}
-
 static inline bool arch_vma_access_permitted(struct vm_area_struct *vma,
 		bool write, bool execute, bool foreign)
 {
diff -puN arch/unicore32/include/asm/mmu_context.h~mpx-remove-generic-mm arch/unicore32/include/asm/mmu_context.h
--- a/arch/unicore32/include/asm/mmu_context.h~mpx-remove-generic-mm	2020-01-23 10:41:07.058942434 -0800
+++ b/arch/unicore32/include/asm/mmu_context.h	2020-01-23 10:41:07.068942434 -0800
@@ -89,11 +89,6 @@ static inline void arch_unmap(struct mm_
 {
 }
 
-static inline void arch_bprm_mm_init(struct mm_struct *mm,
-				     struct vm_area_struct *vma)
-{
-}
-
 static inline bool arch_vma_access_permitted(struct vm_area_struct *vma,
 		bool write, bool execute, bool foreign)
 {
diff -puN arch/x86/include/asm/mmu_context.h~mpx-remove-generic-mm arch/x86/include/asm/mmu_context.h
--- a/arch/x86/include/asm/mmu_context.h~mpx-remove-generic-mm	2020-01-23 10:41:07.060942434 -0800
+++ b/arch/x86/include/asm/mmu_context.h	2020-01-23 10:41:07.069942434 -0800
@@ -272,12 +272,6 @@ static inline bool is_64bit_mm(struct mm
 }
 #endif
 
-static inline void arch_bprm_mm_init(struct mm_struct *mm,
-		struct vm_area_struct *vma)
-{
-	mpx_mm_init(mm);
-}
-
 static inline void arch_unmap(struct mm_struct *mm, unsigned long start,
 			      unsigned long end)
 {
diff -puN fs/exec.c~mpx-remove-generic-mm fs/exec.c
--- a/fs/exec.c~mpx-remove-generic-mm	2020-01-23 10:41:07.062942434 -0800
+++ b/fs/exec.c	2020-01-23 10:41:07.069942434 -0800
@@ -273,7 +273,6 @@ static int __bprm_mm_init(struct linux_b
 		goto err;
 
 	mm->stack_vm = mm->total_vm = 1;
-	arch_bprm_mm_init(mm, vma);
 	up_write(&mm->mmap_sem);
 	bprm->p = vma->vm_end - sizeof(void *);
 	return 0;
diff -puN include/asm-generic/mm_hooks.h~mpx-remove-generic-mm include/asm-generic/mm_hooks.h
--- a/include/asm-generic/mm_hooks.h~mpx-remove-generic-mm	2020-01-23 10:41:07.064942434 -0800
+++ b/include/asm-generic/mm_hooks.h	2020-01-23 10:41:07.069942434 -0800
@@ -22,11 +22,6 @@ static inline void arch_unmap(struct mm_
 {
 }
 
-static inline void arch_bprm_mm_init(struct mm_struct *mm,
-				     struct vm_area_struct *vma)
-{
-}
-
 static inline bool arch_vma_access_permitted(struct vm_area_struct *vma,
 		bool write, bool execute, bool foreign)
 {
_

Re: [PATCH 0/5] x86: finish the MPX removal process

[Linus Torvalds]

Lovely. Thanks. Patches obviously all look fine.

On Thu, Jan 23, 2020 at 11:23 AM Dave Hansen
<dave.hansen@linux.intel.com> wrote:
>
> I'd _rather_ this go in via the x86 tree, but I'm not picky.  I could also
> send a pull request directly to Linus.

I have no strong feelings either way. I'll happily pull this tree for
the 5.6 merge window directly from you, or get it as part of one of
the x86 -tip pull requests.

Up to you and the -tip maintainers, really. Thomas/Ingo/Borislav?

                 Linus

Re: [PATCH 0/5] x86: finish the MPX removal process

[Borislav Petkov]

On Thu, Jan 23, 2020 at 11:26:38AM -0800, Linus Torvalds wrote:
> On Thu, Jan 23, 2020 at 11:23 AM Dave Hansen
> <dave.hansen@linux.intel.com> wrote:
> >
> > I'd _rather_ this go in via the x86 tree, but I'm not picky.

Any particular reason why?

I mean, I don't care a whole lot either - I just don't see the point,
see below.

> I have no strong feelings either way. I'll happily pull this tree for
> the 5.6 merge window directly from you, or get it as part of one of
> the x86 -tip pull requests.
> 
> Up to you and the -tip maintainers, really. Thomas/Ingo/Borislav?

My reasoning to suggest to go directly to you is that there's
practically not a whole lotta sense to add a separate branch to tip,
merge Dave's tree and have a merge commit of the mpx branch only which
you then merge into your master.

Or I can apply each patch separately and then send you that branch so
that there's no pointless merge commit in the history before you merge
it but we get the same if you merge Dave's branch directly...

Oh and btw: I ran a bunch of build smoke tests today of the mpx removal
branch with tip/master merged in and except for a trivial include fix,
there were no issues.

But if someone points out a valid argument why it should go through tip,
I'll gladly do it.

Thx guys.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH 0/5] x86: finish the MPX removal process

[Borislav Petkov]

On Thu, Jan 23, 2020 at 11:26:38AM -0800, Linus Torvalds wrote:
> On Thu, Jan 23, 2020 at 11:23 AM Dave Hansen
> <dave.hansen@linux.intel.com> wrote:
> >
> > I'd _rather_ this go in via the x86 tree, but I'm not picky.

Any particular reason why?

I mean, I don't care a whole lot either - I just don't see the point,
see below.

> I have no strong feelings either way. I'll happily pull this tree for
> the 5.6 merge window directly from you, or get it as part of one of
> the x86 -tip pull requests.
> 
> Up to you and the -tip maintainers, really. Thomas/Ingo/Borislav?

My reasoning to suggest to go directly to you is that there's
practically not a whole lotta sense to add a separate branch to tip,
merge Dave's tree and have a merge commit of the mpx branch only which
you then merge into your master.

Or I can apply each patch separately and then send you that branch so
that there's no pointless merge commit in the history before you merge
it but we get the same if you merge Dave's branch directly...

Oh and btw: I ran a bunch of build smoke tests today of the mpx removal
branch with tip/master merged in and except for a trivial include fix,
there were no issues.

But if someone points out a valid argument why it should go through tip,
I'll gladly do it.

Thx guys.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH 0/5] x86: finish the MPX removal process

[Dave Hansen]

On 1/23/20 12:26 PM, Borislav Petkov wrote:
> On Thu, Jan 23, 2020 at 11:26:38AM -0800, Linus Torvalds wrote:
>> On Thu, Jan 23, 2020 at 11:23 AM Dave Hansen
>> <dave.hansen@linux.intel.com> wrote:
>>> I'd _rather_ this go in via the x86 tree, but I'm not picky.
> Any particular reason why?

I'm confident I can send patches to the x86 maintainers and not make
them too angry.  Sending pull requests to Linus, not so much. :)

I'll just plan to send it to Linus directly.

Re: [PATCH 0/5] x86: finish the MPX removal process

[Dave Hansen]

On 1/23/20 12:26 PM, Borislav Petkov wrote:
> On Thu, Jan 23, 2020 at 11:26:38AM -0800, Linus Torvalds wrote:
>> On Thu, Jan 23, 2020 at 11:23 AM Dave Hansen
>> <dave.hansen@linux.intel.com> wrote:
>>> I'd _rather_ this go in via the x86 tree, but I'm not picky.
> Any particular reason why?

I'm confident I can send patches to the x86 maintainers and not make
them too angry.  Sending pull requests to Linus, not so much. :)

I'll just plan to send it to Linus directly.

Re: [PATCH 0/5] x86: finish the MPX removal process

[Linus Torvalds]

On Thu, Jan 23, 2020 at 1:23 PM Dave Hansen <dave.hansen@intel.com> wrote:
>
> I'm confident I can send patches to the x86 maintainers and not make
> them too angry.  Sending pull requests to Linus, not so much. :)

With a diffstat summary like

 24 files changed, 2 insertions(+), 1697 deletions(-)

there's not a lot I could complain about ;l)

> I'll just plan to send it to Linus directly.

I do note that while I've merged patch series from you before, I don't
seem to have done a git pull from you.

But since you already have a git tree, and the tree looks fine, it
really is just a git request-pull, and you basically already have the
cover-letter to add to the email.

In fact, you don't even have to use a signed tag since it's on
kernel.org - but it's always nice to see, and you can put the cover
letter explanation into the tag.

             Linus