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

[Christophe Leroy <christophe.leroy@csgroup.eu>]

Le 09/06/2022 à 14:57, Jarkko Sakkinen a écrit :
> On Thu, Jun 09, 2022 at 08:30:12AM +0000, Christophe Leroy wrote:
>>
>>
>> Le 08/06/2022 à 01:59, Jarkko Sakkinen a écrit :
>>> [You don't often get email from jarkko@profian.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>>
>>> 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.
>>
>> Nice idea, could also be nice to have BPF without MODULES.
> 
> Yeah, for sure. You have to start from somewhere :-) I'd guess this
> a step forward also for BPF.
> 
>>>
>>> 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.
>>
>> Nice, but that's not enough. You have to audit every peace of code that
>> depends on CONFIG_MODULES and see if it needs to be activated for your
>> case as well. For instance some powerpc configurations don't honor exec
>> page faults on kernel pages when CONFIG_MODULES is not selected.
> 
> Thanks for pointing this out. With "every peace of code" you probably
> are referring to the 13 arch-folders, which support kprobes in the first
> place (just checking)?

In a way yes, I was mainly thinking about the dozen of places in 
arch/powerpc/ to begin with. And also to check the 30 places with 
CONFIG_MODULES in includes/ directory which contains things that may be 
used by architectures.