On Wed, 29 Jul 2020 at 04:51, Masami Hiramatsu <mhira...@kernel.org> wrote:
>
> On Tue, 28 Jul 2020 20:51:08 +0300
> Ard Biesheuvel <a...@kernel.org> wrote:
>
> > On Tue, 28 Jul 2020 at 16:35, Masami Hiramatsu <mhira...@kernel.org> wrote:
> > >
> > > On Tue, 28 Jul 2020 13:56:43 +0300
> > > Ard Biesheuvel <a...@kernel.org> wrote:
> > >
> > > > On Tue, 28 Jul 2020 at 11:17, Masami Hiramatsu <mhira...@kernel.org> 
> > > > wrote:
> > > > > > Masami or Peter should correct me if I am wrong, but it seems to me
> > > > > > that the way kprobes uses these pages does not require them to be in
> > > > > > relative branching range of the core kernel on any architecture, 
> > > > > > given
> > > > > > that they are populated with individual instruction opcodes that are
> > > > > > executed in single step mode, and relative branches are emulated 
> > > > > > (when
> > > > > > needed)
> > > > >
> > > > > Actually, x86 and arm has the "relative branching range" requirements
> > > > > for the jump optimized kprobes. For the other architectures, I think
> > > > > we don't need it. Only executable text buffer is needed.
> > > > >
> > > >
> > > > Thanks for the explanation. Today, arm64 uses the definition below.
> > > >
> > > > void *alloc_insn_page(void)
> > > > {
> > > >   return __vmalloc_node_range(PAGE_SIZE, 1, VMALLOC_START, VMALLOC_END,
> > > >     GFP_KERNEL, PAGE_KERNEL_ROX, VM_FLUSH_RESET_PERMS,
> > > >     NUMA_NO_NODE, __builtin_return_address(0));
> > > > }
> > > >
> > > > Do you think we could use that as the generic implementation if we use
> > > > MODULES_START/_END as the allocation window?
> > >
> > > Yes, but for the generic implementation, we don't need to consider the
> > > relative branching range since we can override it for x86 and arm.
> > > (and that will be almost same as module_alloc() default code)
> >
> > Indeed. So having kprobes specific macros that default to
> > VMALLOC_START/END but can be overridden would be sufficient.
> >
> > > BTW, is PAGE_KERNEL_ROX flag available generically?
> > >
> >
> > Turns out that it is not :-(
>
> Hmm, in that case, we need to use PAGE_KERNEL_EXEC.
>
> In the result, may it be similar to this? :)
>
> void * __weak module_alloc(unsigned long size)
> {
>         return __vmalloc_node_range(size, 1, VMALLOC_START, VMALLOC_END,
>                         GFP_KERNEL, PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS,
>                         NUMA_NO_NODE, __builtin_return_address(0));
> }
>
> The major difference between module_alloc() and kprobe's alloc_page_insn()
> is the alloc_page_insn() makes the page ROX after allocating the pages *ONLY*
> on x86 and arm64.
>

Right.

> $ git grep -w alloc_insn_page -- arch
> arch/arm64/kernel/probes/kprobes.c:void *alloc_insn_page(void)
> arch/x86/kernel/kprobes/core.c:void *alloc_insn_page(void)
>
> However since the module_alloc() owns its arch-dependent implementations
> most of major architectures, if we implement independent text_alloc_kprobe(),
> we need to make deadcopies of module_alloc() for each architecture.
>

No, that is what we are trying to avoid.

> $ git grep 'module_alloc(unsigned' arch/
> arch/arm/kernel/module.c:void *module_alloc(unsigned long size)
> arch/arm64/kernel/module.c:void *module_alloc(unsigned long size)
> arch/mips/kernel/module.c:void *module_alloc(unsigned long size)
> arch/nds32/kernel/module.c:void *module_alloc(unsigned long size)
> arch/nios2/kernel/module.c:void *module_alloc(unsigned long size)
> arch/parisc/kernel/module.c:void *module_alloc(unsigned long size)
> arch/riscv/kernel/module.c:void *module_alloc(unsigned long size)
> arch/s390/kernel/module.c:void *module_alloc(unsigned long size)
> arch/sparc/kernel/module.c:void *module_alloc(unsigned long size)
> arch/unicore32/kernel/module.c:void *module_alloc(unsigned long size)
> arch/x86/kernel/module.c:void *module_alloc(unsigned long size)
>
> It seems that some constrains for module_alloc() exists for above
> architectures.
>
> Anyway, for kprobe's text_alloc() requirements are
> - It must be executable for the arch which uses a single-step out-of-line.
>   (and need to be registered to KASAN?)

No, kasan shadow is not needed here.

> - It must be ROX if implemented (currently only for x86 and arm64)

x86 does not actually define thr macro, but the result is the same.

> - It must be in the range of relative branching only for x86 and arm.
>

So in summary, the generic module_alloc() above can be reused for
kprobes on all arches except x86 and arm64, right? Then we can remove
the call to it, and drop the modules dependency.

Reply via email to