On Wed, Jun 8, 2022 at 9:28 AM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > Hello Jarkko, > > On Wed, 8 Jun 2022 at 02:02, Jarkko Sakkinen <jarkko@xxxxxxxxxxx> wrote: > > > > Tracing with kprobes while running a monolithic kernel is currently > > impossible because CONFIG_KPROBES is dependent of CONFIG_MODULES. This > > dependency is a result of kprobes code using the module allocator for the > > trampoline code. > > > > Detaching kprobes from modules helps to squeeze down the user space, > > e.g. when developing new core kernel features, while still having all > > the nice tracing capabilities. > > > > For kernel/ and arch/*, move module_alloc() and module_memfree() to > > module_alloc.c, and compile as part of vmlinux when either CONFIG_MODULES > > or CONFIG_KPROBES is enabled. In addition, flag kernel module specific > > code with CONFIG_MODULES. > > > > As the result, kprobes can be used with a monolithic kernel. > > I think I may have mentioned this the previous time as well, but I > don't think this is the right approach. > > Kprobes uses alloc_insn_page() to allocate executable memory, but the > requirements for this memory are radically different compared to > loadable modules, which need to be within an arch-specific distance of > the core kernel, need KASAN backing etc etc. I think the distance of core kernel requirement is the same for kprobe alloc_insn_page and modules, no? Thanks, Song > > This is why arm64, for instance, does not implement alloc_insn_page() > in terms of module_alloc() [and likely does not belong in this patch > for that reason] > > Is there any reason kprobes cannot simply use vmalloc()? >
