Re: [PATCH] kprobes: Enable tracing for mololithic kernel images

[Masami Hiramatsu (Google) <mhiramat@kernel.org>]

el.org>, Masahiro Yamada <masahiroy@kernel.org>, Jarkko Sakkinen <jarkko@profian.com>, Sami Tolvanen <samitolvanen@google.com>, "Naveen N. Rao" <naveen.n.rao@linux.ibm.com>, Marco Elver <elver@google.com>, Kees Cook <keescook@chromium.org>, Steven Rostedt <rostedt@goodmis.org>, Nathan Chancellor <nathan@kernel.org>, "Russell King \(Oracle\)" <rmk+kernel@armlinux.org.uk>, Mark Brown <broonie@kernel.org>, Borislav Petkov <bp@alien8.de>, Alexander Egorenkov <egorenar@linux.ibm.com>, Thomas Bogendoerfer <tsbogend@alpha.franken.de>, Parisc List <linux-parisc@vger.kernel.org>, Nathaniel McCallum <nathaniel@profian.com>, Dmitry Torokhov <dmitry.torokhov@gmail.com>, "David S. Miller" <davem@davemloft.net>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, Tobias Huschle <huschle@linux.ibm.com>, "Peter Zijlstra \(Intel\)" <peterz@infradead.org>, "H. Peter Anvin" <hpa@zytor.com>, sparclinux <sparclinux@vger.kernel.org>, Tiezhu Yang <yangtiezhu@loongson.cn>, Miroslav Benes <mbenes@suse.cz
 >, Chen Zhongjin <chenzhongjin@huawei.com>, Ard Biesheuvel <ardb@kernel.org>, the arch/x86 maintainers <x86@kernel.org>, Russell King <linux@armlinux.org.uk>, linux-riscv <linux-riscv@lists.infradead.org>, Ingo Molnar <mingo@redhat.com>, Aaron Tomlin <atomlin@redhat.com>, Albert Ou <aou@eecs.berkeley.edu>, Heiko Carstens <hca@linux.ibm.com>, Liao Chang <liaochang1@huawei.com>, Paul Walmsley <paul.walmsley@sifive.com>, Josh Poimboeuf <jpoimboe@kernel.org>, Thomas Richter <tmricht@linux.ibm.com>, "open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>, Changbin Du <changbin.du@intel.com>, Palmer Dabbelt <palmer@dabbelt.com>, linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, "linux-modules@vger.kernel.org" <linux-modules@vger.kernel.org>
Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org
Sender: "Linuxppc-dev" <linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org>

On Sun, 12 Jun 2022 15:59:29 +0000
Christophe Leroy <christophe.leroy@csgroup.eu> wrote:

> 
> 
> Le 12/06/2022 à 14:18, Masami Hiramatsu (Google) a écrit :
> > [You don't often get email from mhiramat@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > 
> > On Thu, 9 Jun 2022 15:23:16 +0200
> > Ard Biesheuvel <ardb@kernel.org> wrote:
> > 
> >> On Thu, 9 Jun 2022 at 15:14, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >>>
> >>> On Wed, Jun 08, 2022 at 09:12:34AM -0700, Song Liu wrote:
> >>>> On Wed, Jun 8, 2022 at 7:21 AM Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >>>>>
> >>>>> Hi Jarkko,
> >>>>>
> >>>>> On Wed, 8 Jun 2022 08:25:38 +0300
> >>>>> Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >>>>>
> >>>>>> On Wed, Jun 08, 2022 at 10:35:42AM +0800, Guo Ren wrote:
> >>>>>>> .
> >>>>>>>
> >>>>>>> On Wed, Jun 8, 2022 at 8:02 AM Jarkko Sakkinen <jarkko@profian.com> 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.
> >>>>>>> It's strange when MODULES is n, but vmlinux still obtains module_alloc.
> >>>>>>>
> >>>>>>> Maybe we need a kprobe_alloc, right?
> >>>>>>
> >>>>>> Perhaps not the best name but at least it documents the fact that
> >>>>>> they use the same allocator.
> >>>>>>
> >>>>>> Few years ago I carved up something "half-way there" for kprobes,
> >>>>>> and I used the name text_alloc() [*].
> >>>>>>
> >>>>>> [*] https://lore.kernel.org/all/20200724050553.1724168-1-jarkko.sakkinen@linux.intel.com/
> >>>>>
> >>>>> Yeah, I remember that. Thank you for updating your patch!
> >>>>> I think the idea (split module_alloc() from CONFIG_MODULE) is good to me.
> >>>>> If module support maintainers think this name is not good, you may be
> >>>>> able to rename it as text_alloc() and make the module_alloc() as a
> >>>>> wrapper of it.
> >>>>
> >>>> IIUC, most users of module_alloc() use it to allocate memory for text, except
> >>>> that module code uses it for both text and data. Therefore, I guess calling it
> >>>> text_alloc() is not 100% accurate until we change the module code (to use
> >>>> a different API to allocate memory for data).
> >>>
> >>> After reading the feedback, I'd stay on using module_alloc() because
> >>> it has arch-specific quirks baked in. Easier to deal with them in one
> >>> place.
> >>>
> >>
> >> In that case, please ensure that you enable this only on architectures
> >> where it is needed. arm64 implements alloc_insn_page() without relying
> >> on module_alloc() so I would not expect to see any changes there.
> > 
> > Hmm, what about adding CONFIG_ARCH_HAVE_ALLOC_INSN_PAGE and check it?
> > If it is defined, kprobes will not define the __weak function, but
> > if not, it will use module_alloc()?
> > 
> 
> I'm not sure I understand. What's the problem with the __weak function 
> here ?
> 
> If we don't define the __weak alloc_insn_page() when arch has 
> CONFIG_ARCH_HAVE_ALLOC_INSN_PAGE, then what's the point in making it weak ?
> 
> powerpc has it's own alloc_insn_page(), but calls module_alloc(). So how 
> will it work ?

Good point! In that case, it will need to separate the module_alloc()
from kmodule support even without the __weak.

Thank you,

> 
> void *alloc_insn_page(void)
> {
> 	void *page;
> 
> 	page = module_alloc(PAGE_SIZE);
> 	if (!page)
> 		return NULL;
> 
> 	if (strict_module_rwx_enabled()) {
> 		set_memory_ro((unsigned long)page, 1);
> 		set_memory_x((unsigned long)page, 1);
> 	}
> 	return page;
> }
> 
> Christophe

-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>