| Message ID | 20190523102256.29168-1-ard.biesheuvel@arm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: wire up VM_FLUSH_RESET_PERMS | expand |
On Thu, May 23, 2019 at 11:22:52AM +0100, Ard Biesheuvel wrote: > Wire up the code introduced in v5.2 to manage the permissions > of executable vmalloc regions (and their linear aliases) more > strictly. > > One of the things that came up in the internal discussion is > whether non-x86 architectures have any benefit at all from the > lazy vunmap feature, and whether it would perhaps be better to > implement eager vunmap instead. > > Cc: Nadav Amit <namit@vmware.com> > Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: Will Deacon <will.deacon@arm.com> > Cc: Masami Hiramatsu <mhiramat@kernel.org> > Cc: James Morse <james.morse@arm.com> > > Ard Biesheuvel (4): > arm64: module: create module allocations without exec permissions > arm64/mm: wire up CONFIG_ARCH_HAS_SET_DIRECT_MAP > arm64/kprobes: set VM_FLUSH_RESET_PERMS on kprobe instruction pages > arm64: bpf: do not allocate executable memory > > arch/arm64/Kconfig | 1 + > arch/arm64/include/asm/cacheflush.h | 3 ++ > arch/arm64/kernel/module.c | 4 +- > arch/arm64/kernel/probes/kprobes.c | 4 +- > arch/arm64/mm/pageattr.c | 48 ++++++++++++++++---- > arch/arm64/net/bpf_jit_comp.c | 2 +- > mm/vmalloc.c | 11 ----- > 7 files changed, 50 insertions(+), 23 deletions(-) Thanks, this all looks good to me. I can get pick this up for 5.2 if Rick's fixes [1] land soon enough. Cheers, Will [1] https://lore.kernel.org/lkml/20190527211058.2729-1-rick.p.edgecombe@intel.com/T/#u
On 5/28/19 12:04 PM, Will Deacon wrote: > On Thu, May 23, 2019 at 11:22:52AM +0100, Ard Biesheuvel wrote: >> Wire up the code introduced in v5.2 to manage the permissions >> of executable vmalloc regions (and their linear aliases) more >> strictly. >> >> One of the things that came up in the internal discussion is >> whether non-x86 architectures have any benefit at all from the >> lazy vunmap feature, and whether it would perhaps be better to >> implement eager vunmap instead. >> >> Cc: Nadav Amit <namit@vmware.com> >> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> >> Cc: Peter Zijlstra <peterz@infradead.org> >> Cc: Andrew Morton <akpm@linux-foundation.org> >> Cc: Will Deacon <will.deacon@arm.com> >> Cc: Masami Hiramatsu <mhiramat@kernel.org> >> Cc: James Morse <james.morse@arm.com> >> >> Ard Biesheuvel (4): >> arm64: module: create module allocations without exec permissions >> arm64/mm: wire up CONFIG_ARCH_HAS_SET_DIRECT_MAP >> arm64/kprobes: set VM_FLUSH_RESET_PERMS on kprobe instruction pages >> arm64: bpf: do not allocate executable memory >> >> arch/arm64/Kconfig | 1 + >> arch/arm64/include/asm/cacheflush.h | 3 ++ >> arch/arm64/kernel/module.c | 4 +- >> arch/arm64/kernel/probes/kprobes.c | 4 +- >> arch/arm64/mm/pageattr.c | 48 ++++++++++++++++---- >> arch/arm64/net/bpf_jit_comp.c | 2 +- >> mm/vmalloc.c | 11 ----- >> 7 files changed, 50 insertions(+), 23 deletions(-) > > Thanks, this all looks good to me. I can get pick this up for 5.2 if > Rick's fixes [1] land soon enough. > Note that you'll get a trivial conflict in the hunk against mm/vmalloc.c.
On Tue, May 28, 2019 at 11:04:20AM +0100, Will Deacon wrote: > On Thu, May 23, 2019 at 11:22:52AM +0100, Ard Biesheuvel wrote: > > Wire up the code introduced in v5.2 to manage the permissions > > of executable vmalloc regions (and their linear aliases) more > > strictly. > > > > One of the things that came up in the internal discussion is > > whether non-x86 architectures have any benefit at all from the > > lazy vunmap feature, and whether it would perhaps be better to > > implement eager vunmap instead. > > > > Cc: Nadav Amit <namit@vmware.com> > > Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> > > Cc: Peter Zijlstra <peterz@infradead.org> > > Cc: Andrew Morton <akpm@linux-foundation.org> > > Cc: Will Deacon <will.deacon@arm.com> > > Cc: Masami Hiramatsu <mhiramat@kernel.org> > > Cc: James Morse <james.morse@arm.com> > > > > Ard Biesheuvel (4): > > arm64: module: create module allocations without exec permissions > > arm64/mm: wire up CONFIG_ARCH_HAS_SET_DIRECT_MAP > > arm64/kprobes: set VM_FLUSH_RESET_PERMS on kprobe instruction pages > > arm64: bpf: do not allocate executable memory > > > > arch/arm64/Kconfig | 1 + > > arch/arm64/include/asm/cacheflush.h | 3 ++ > > arch/arm64/kernel/module.c | 4 +- > > arch/arm64/kernel/probes/kprobes.c | 4 +- > > arch/arm64/mm/pageattr.c | 48 ++++++++++++++++---- > > arch/arm64/net/bpf_jit_comp.c | 2 +- > > mm/vmalloc.c | 11 ----- > > 7 files changed, 50 insertions(+), 23 deletions(-) > > Thanks, this all looks good to me. I can get pick this up for 5.2 if > Rick's fixes [1] land soon enough. Bah, I missed these landing in -rc5 and I think it's a bit too late for us to take this for 5.2. now particularly with our limited ability to fix any late regressions that might arise. In which case, Catalin, please can you take these for 5.3? You might run into some testing failures with for-next/core due to the late of Rick's fixes, but linux-next should be alright and I don't think you'll get any conflicts. Acked-by: Will Deacon <will@kernel.org> Ard: are you ok with that? Thanks, Will
On 6/24/19 1:16 PM, Will Deacon wrote: > On Tue, May 28, 2019 at 11:04:20AM +0100, Will Deacon wrote: >> On Thu, May 23, 2019 at 11:22:52AM +0100, Ard Biesheuvel wrote: >>> Wire up the code introduced in v5.2 to manage the permissions >>> of executable vmalloc regions (and their linear aliases) more >>> strictly. >>> >>> One of the things that came up in the internal discussion is >>> whether non-x86 architectures have any benefit at all from the >>> lazy vunmap feature, and whether it would perhaps be better to >>> implement eager vunmap instead. >>> >>> Cc: Nadav Amit <namit@vmware.com> >>> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> >>> Cc: Peter Zijlstra <peterz@infradead.org> >>> Cc: Andrew Morton <akpm@linux-foundation.org> >>> Cc: Will Deacon <will.deacon@arm.com> >>> Cc: Masami Hiramatsu <mhiramat@kernel.org> >>> Cc: James Morse <james.morse@arm.com> >>> >>> Ard Biesheuvel (4): >>> arm64: module: create module allocations without exec permissions >>> arm64/mm: wire up CONFIG_ARCH_HAS_SET_DIRECT_MAP >>> arm64/kprobes: set VM_FLUSH_RESET_PERMS on kprobe instruction pages >>> arm64: bpf: do not allocate executable memory >>> >>> arch/arm64/Kconfig | 1 + >>> arch/arm64/include/asm/cacheflush.h | 3 ++ >>> arch/arm64/kernel/module.c | 4 +- >>> arch/arm64/kernel/probes/kprobes.c | 4 +- >>> arch/arm64/mm/pageattr.c | 48 ++++++++++++++++---- >>> arch/arm64/net/bpf_jit_comp.c | 2 +- >>> mm/vmalloc.c | 11 ----- >>> 7 files changed, 50 insertions(+), 23 deletions(-) >> >> Thanks, this all looks good to me. I can get pick this up for 5.2 if >> Rick's fixes [1] land soon enough. > > Bah, I missed these landing in -rc5 and I think it's a bit too late for > us to take this for 5.2. now particularly with our limited ability to > fix any late regressions that might arise. > > In which case, Catalin, please can you take these for 5.3? You might run > into some testing failures with for-next/core due to the late of Rick's > fixes, but linux-next should be alright and I don't think you'll get any > conflicts. > > Acked-by: Will Deacon <will@kernel.org> > > Ard: are you ok with that? > That is fine, although I won't be around to pick up the pieces by the time the merge window opens. Also, I'd like to follow up on the lazy vunmap thing for non-x86, but perhaps we can talk about this at plumbers?
(+ Catalin) On Mon, 24 Jun 2019 at 13:23, Ard Biesheuvel <ard.biesheuvel@arm.com> wrote: > > On 6/24/19 1:16 PM, Will Deacon wrote: > > On Tue, May 28, 2019 at 11:04:20AM +0100, Will Deacon wrote: > >> On Thu, May 23, 2019 at 11:22:52AM +0100, Ard Biesheuvel wrote: > >>> Wire up the code introduced in v5.2 to manage the permissions > >>> of executable vmalloc regions (and their linear aliases) more > >>> strictly. > >>> > >>> One of the things that came up in the internal discussion is > >>> whether non-x86 architectures have any benefit at all from the > >>> lazy vunmap feature, and whether it would perhaps be better to > >>> implement eager vunmap instead. > >>> > >>> Cc: Nadav Amit <namit@vmware.com> > >>> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> > >>> Cc: Peter Zijlstra <peterz@infradead.org> > >>> Cc: Andrew Morton <akpm@linux-foundation.org> > >>> Cc: Will Deacon <will.deacon@arm.com> > >>> Cc: Masami Hiramatsu <mhiramat@kernel.org> > >>> Cc: James Morse <james.morse@arm.com> > >>> > >>> Ard Biesheuvel (4): > >>> arm64: module: create module allocations without exec permissions > >>> arm64/mm: wire up CONFIG_ARCH_HAS_SET_DIRECT_MAP > >>> arm64/kprobes: set VM_FLUSH_RESET_PERMS on kprobe instruction pages > >>> arm64: bpf: do not allocate executable memory > >>> > >>> arch/arm64/Kconfig | 1 + > >>> arch/arm64/include/asm/cacheflush.h | 3 ++ > >>> arch/arm64/kernel/module.c | 4 +- > >>> arch/arm64/kernel/probes/kprobes.c | 4 +- > >>> arch/arm64/mm/pageattr.c | 48 ++++++++++++++++---- > >>> arch/arm64/net/bpf_jit_comp.c | 2 +- > >>> mm/vmalloc.c | 11 ----- > >>> 7 files changed, 50 insertions(+), 23 deletions(-) > >> > >> Thanks, this all looks good to me. I can get pick this up for 5.2 if > >> Rick's fixes [1] land soon enough. > > > > Bah, I missed these landing in -rc5 and I think it's a bit too late for > > us to take this for 5.2. now particularly with our limited ability to > > fix any late regressions that might arise. > > > > In which case, Catalin, please can you take these for 5.3? You might run > > into some testing failures with for-next/core due to the late of Rick's > > fixes, but linux-next should be alright and I don't think you'll get any > > conflicts. > > > > Acked-by: Will Deacon <will@kernel.org> > > > > Ard: are you ok with that? > > > > That is fine, although I won't be around to pick up the pieces by the > time the merge window opens. Also, I'd like to follow up on the lazy > vunmap thing for non-x86, but perhaps we can talk about this at plumbers? > Actually, you will run into a couple of conflicts. Let me know if you want me to respin (although they still won't apply cleanly to both for-next/core and -next)
On Mon, Jun 24, 2019 at 04:29:39PM +0200, Ard Biesheuvel wrote: > On Mon, 24 Jun 2019 at 13:23, Ard Biesheuvel <ard.biesheuvel@arm.com> wrote: > > On 6/24/19 1:16 PM, Will Deacon wrote: > > > On Tue, May 28, 2019 at 11:04:20AM +0100, Will Deacon wrote: > > >> On Thu, May 23, 2019 at 11:22:52AM +0100, Ard Biesheuvel wrote: > > >>> Ard Biesheuvel (4): > > >>> arm64: module: create module allocations without exec permissions > > >>> arm64/mm: wire up CONFIG_ARCH_HAS_SET_DIRECT_MAP > > >>> arm64/kprobes: set VM_FLUSH_RESET_PERMS on kprobe instruction pages > > >>> arm64: bpf: do not allocate executable memory > > >>> > > >>> arch/arm64/Kconfig | 1 + > > >>> arch/arm64/include/asm/cacheflush.h | 3 ++ > > >>> arch/arm64/kernel/module.c | 4 +- > > >>> arch/arm64/kernel/probes/kprobes.c | 4 +- > > >>> arch/arm64/mm/pageattr.c | 48 ++++++++++++++++---- > > >>> arch/arm64/net/bpf_jit_comp.c | 2 +- > > >>> mm/vmalloc.c | 11 ----- > > >>> 7 files changed, 50 insertions(+), 23 deletions(-) > > >> > > >> Thanks, this all looks good to me. I can get pick this up for 5.2 if > > >> Rick's fixes [1] land soon enough. > > > > > > Bah, I missed these landing in -rc5 and I think it's a bit too late for > > > us to take this for 5.2. now particularly with our limited ability to > > > fix any late regressions that might arise. > > > > > > In which case, Catalin, please can you take these for 5.3? You might run > > > into some testing failures with for-next/core due to the late of Rick's > > > fixes, but linux-next should be alright and I don't think you'll get any > > > conflicts. > > > > > > Acked-by: Will Deacon <will@kernel.org> > > > > > > Ard: are you ok with that? > > > > That is fine, although I won't be around to pick up the pieces by the > > time the merge window opens. Also, I'd like to follow up on the lazy > > vunmap thing for non-x86, but perhaps we can talk about this at plumbers? > > Actually, you will run into a couple of conflicts. Let me know if you > want me to respin (although they still won't apply cleanly to both > for-next/core and -next) I queued them in for-next/core (and fixed a minor conflict). Thanks.
On Mon, 24 Jun 2019 at 19:14, Catalin Marinas <catalin.marinas@arm.com> wrote: > > On Mon, Jun 24, 2019 at 04:29:39PM +0200, Ard Biesheuvel wrote: > > On Mon, 24 Jun 2019 at 13:23, Ard Biesheuvel <ard.biesheuvel@arm.com> wrote: > > > On 6/24/19 1:16 PM, Will Deacon wrote: > > > > On Tue, May 28, 2019 at 11:04:20AM +0100, Will Deacon wrote: > > > >> On Thu, May 23, 2019 at 11:22:52AM +0100, Ard Biesheuvel wrote: > > > >>> Ard Biesheuvel (4): > > > >>> arm64: module: create module allocations without exec permissions > > > >>> arm64/mm: wire up CONFIG_ARCH_HAS_SET_DIRECT_MAP > > > >>> arm64/kprobes: set VM_FLUSH_RESET_PERMS on kprobe instruction pages > > > >>> arm64: bpf: do not allocate executable memory > > > >>> > > > >>> arch/arm64/Kconfig | 1 + > > > >>> arch/arm64/include/asm/cacheflush.h | 3 ++ > > > >>> arch/arm64/kernel/module.c | 4 +- > > > >>> arch/arm64/kernel/probes/kprobes.c | 4 +- > > > >>> arch/arm64/mm/pageattr.c | 48 ++++++++++++++++---- > > > >>> arch/arm64/net/bpf_jit_comp.c | 2 +- > > > >>> mm/vmalloc.c | 11 ----- > > > >>> 7 files changed, 50 insertions(+), 23 deletions(-) > > > >> > > > >> Thanks, this all looks good to me. I can get pick this up for 5.2 if > > > >> Rick's fixes [1] land soon enough. > > > > > > > > Bah, I missed these landing in -rc5 and I think it's a bit too late for > > > > us to take this for 5.2. now particularly with our limited ability to > > > > fix any late regressions that might arise. > > > > > > > > In which case, Catalin, please can you take these for 5.3? You might run > > > > into some testing failures with for-next/core due to the late of Rick's > > > > fixes, but linux-next should be alright and I don't think you'll get any > > > > conflicts. > > > > > > > > Acked-by: Will Deacon <will@kernel.org> > > > > > > > > Ard: are you ok with that? > > > > > > That is fine, although I won't be around to pick up the pieces by the > > > time the merge window opens. Also, I'd like to follow up on the lazy > > > vunmap thing for non-x86, but perhaps we can talk about this at plumbers? > > > > Actually, you will run into a couple of conflicts. Let me know if you > > want me to respin (although they still won't apply cleanly to both > > for-next/core and -next) > > I queued them in for-next/core (and fixed a minor conflict). Thanks. > OK, in that case, you will get a conflict in -next on the hunk against mm/vmalloc.c in the second patch. Just FYI ...