linux-kernel - Re: [PATCH 1/2] livepatch: Fix having __klp_objects relics in non-livepatch modules

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c753a5cc-e654-433c-84be-189185182250@suse.com>
Date: Tue, 20 Jan 2026 18:48:45 +0100
From: Petr Pavlu <petr.pavlu@...e.com>
To: Joe Lawrence <joe.lawrence@...hat.com>
Cc: Josh Poimboeuf <jpoimboe@...nel.org>, Jiri Kosina <jikos@...nel.org>,
 Miroslav Benes <mbenes@...e.cz>, Petr Mladek <pmladek@...e.com>,
 Luis Chamberlain <mcgrof@...nel.org>, Daniel Gomez <da.gomez@...nel.org>,
 Sami Tolvanen <samitolvanen@...gle.com>, Aaron Tomlin <atomlin@...mlin.com>,
 Peter Zijlstra <peterz@...radead.org>, live-patching@...r.kernel.org,
 linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] livepatch: Fix having __klp_objects relics in
 non-livepatch modules

On 1/19/26 11:19 PM, Joe Lawrence wrote:
> On Wed, Jan 14, 2026 at 01:29:53PM +0100, Petr Pavlu wrote:
>> The linker script scripts/module.lds.S specifies that all input
>> __klp_objects sections should be consolidated into an output section of
>> the same name, and start/stop symbols should be created to enable
>> scripts/livepatch/init.c to locate this data.
>>
>> This start/stop pattern is not ideal for modules because the symbols are
>> created even if no __klp_objects input sections are present.
>> Consequently, a dummy __klp_objects section also appears in the
>> resulting module. This unnecessarily pollutes non-livepatch modules.
>>
>> Instead, since modules are relocatable files, the usual method for
>> locating consolidated data in a module is to read its section table.
>> This approach avoids the aforementioned problem.
>>
>> The klp_modinfo already stores a copy of the entire section table with
>> the final addresses. Introduce a helper function that
>> scripts/livepatch/init.c can call to obtain the location of the
>> __klp_objects section from this data.
>>
>> Signed-off-by: Petr Pavlu <petr.pavlu@...e.com>
>> ---
>>  include/linux/livepatch.h |  3 +++
>>  kernel/livepatch/core.c   | 20 ++++++++++++++++++++
>>  scripts/livepatch/init.c  | 17 ++++++-----------
>>  scripts/module.lds.S      |  7 +------
>>  4 files changed, 30 insertions(+), 17 deletions(-)
>>
>> diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
>> index 772919e8096a..ca90adbe89ed 100644
>> --- a/include/linux/livepatch.h
>> +++ b/include/linux/livepatch.h
>> @@ -175,6 +175,9 @@ int klp_enable_patch(struct klp_patch *);
>>  int klp_module_coming(struct module *mod);
>>  void klp_module_going(struct module *mod);
>>  
>> +struct klp_object_ext *klp_build_locate_init_objects(const struct module *mod,
>> +						     unsigned int *nr_objs);
>> +
>>  void klp_copy_process(struct task_struct *child);
>>  void klp_update_patch_state(struct task_struct *task);
>>  
>> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
>> index 9917756dae46..4e0ac47b3623 100644
>> --- a/kernel/livepatch/core.c
>> +++ b/kernel/livepatch/core.c
>> @@ -1356,6 +1356,26 @@ void klp_module_going(struct module *mod)
>>  	mutex_unlock(&klp_mutex);
>>  }
>>  
>> +struct klp_object_ext *klp_build_locate_init_objects(const struct module *mod,
>> +						     unsigned int *nr_objs)
>> +{
>> +	struct klp_modinfo *info = mod->klp_info;
>> +
>> +	for (int i = 1; i < info->hdr.e_shnum; i++) {
>> +		Elf_Shdr *shdr = &info->sechdrs[i];
>> +
>> +		if (strcmp(info->secstrings + shdr->sh_name, "__klp_objects"))
>> +			continue;
>> +
> 
> Since this function is doing a string comparision to find the ELF
> section, would it make sense to open up the API by allowing to caller to
> specify the sh_name?  That would give scripts/livepatch/init.c future
> flexibility in finding similarly crafted data structures.  Disregard if
> there is already a pattern of doing it this way :)

Makes sense. I'll change the function signature to:

void *klp_locate_section_objs(const struct module *mod, const char *name, size_t object_size, unsigned int *nr_objs);

-- 
Thanks,
Petr