[PATCH] kprobes: Enable tracing for mololithic kernel images

[Christophe Leroy]

Le 12/06/2022 à 14:18, Masami Hiramatsu (Google) a écrit :
> [You don't often get email from mhiramat at kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> On Thu, 9 Jun 2022 15:23:16 +0200
> Ard Biesheuvel <ardb at kernel.org> wrote:
> 
>> On Thu, 9 Jun 2022 at 15:14, Jarkko Sakkinen <jarkko at 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 at kernel.org> wrote:
>>>>>
>>>>> Hi Jarkko,
>>>>>
>>>>> On Wed, 8 Jun 2022 08:25:38 +0300
>>>>> Jarkko Sakkinen <jarkko at 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 at 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 ?

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