Re: [PATCH 0/4] arm64: wire up VM_FLUSH_RESET_PERMS

[Will Deacon]

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@xxxxxxxxxx>
> > Cc: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
> > Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> > Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> > Cc: Will Deacon <will.deacon@xxxxxxx>
> > Cc: Masami Hiramatsu <mhiramat@xxxxxxxxxx>
> > Cc: James Morse <james.morse@xxxxxxx>
> > 
> > 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@xxxxxxxxxx>

Ard: are you ok with that?

Thanks,

Will