hiro Yamada <[email protected]>, Jarkko Sakkinen <[email protected]>, Sami Tolvanen <[email protected]>, "Naveen N. Rao" <[email protected]>, Marco Elver <[email protected]>, Kees Cook <[email protected]>, Steven Rostedt <[email protected]>, Nathan Chancellor <[email protected]>, "Russell King \(Oracle\)" <[email protected]>, Mark Brown <[email protected]>, Borislav Petkov <[email protected]>, Alexander Egorenkov <[email protected]>, Thomas Bogendoerfer <[email protected]>, [email protected], Nathaniel McCallum <[email protected]>, Dmitry Torokhov <[email protected]>, "David S. Miller" <[email protected]>, "Kirill A. Shutemov" <[email protected]>, Tobias Huschle <[email protected]>, "Peter Zijlstra \(Intel\)" <[email protected]>, "H. Peter Anvin" <[email protected]>, [email protected], Tiezhu Yang <[email protected]>, Miroslav Benes <[email protected]>, Chen Zhongjin <[email protected] m>, Ard Biesheuvel <[email protected]>, X86 ML <[email protected]>, Russell King <[email protected]>, [email protected], Ingo Molnar <[email protected]>, Aaron Tomlin <[email protected]>, Albert Ou <[email protected]>, Heiko Carstens <[email protected]>, Liao Chang <[email protected]>, Paul Walmsley <[email protected]>, Josh Poimboeuf <[email protected]>, Thomas Richter <[email protected]>, [email protected], Changbin Du <[email protected]>, Palmer Dabbelt <[email protected]>, [email protected], [email protected] Errors-To: [email protected] Sender: "Linuxppc-dev" <[email protected]>
On Wed, 8 Jun 2022 11:19:19 -0700 Song Liu <[email protected]> wrote: > On Wed, Jun 8, 2022 at 9:28 AM Ard Biesheuvel <[email protected]> wrote: > > > > Hello Jarkko, > > > > On Wed, 8 Jun 2022 at 02:02, Jarkko Sakkinen <[email protected]> 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? This strongly depends on how kprobes (software breakpoint and single-step) is implemented on the arch. For example, x86 implements the so-called "kprobe-booster" which jumps back from the single stepping trampoline buffer. Then the buffer address must be within the range where it can jump to the original address. However, if the arch implements single-step as an instruction emulation, it has no such limitation. As far as I know, arm64 will do emulation for the instructions which change PC register and will do direct execution with another software breakpoint for other instructions. Why I'm using module_alloc() for a generic function, is that can cover the limitation most widely. Thus, if we have CONFIG_ARCH_HAVE_ALLOC_INSN_PAGE flag and kprobes can check it instead of using __weak function, the kprobes may not need to depend on module_alloc() in general. Thank you, > > 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()? > > -- Masami Hiramatsu (Google) <[email protected]>
