From: Petr Mladek <pmladek@suse.com>
To: zhang warden <zhangwarden@gmail.com>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
Jiri Kosina <jikos@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
Joe Lawrence <joe.lawrence@redhat.com>,
live-patching@vger.kernel.org
Subject: Re: [RFC] Add target module check before livepatch module loading
Date: Tue, 11 Mar 2025 13:25:29 +0100 [thread overview]
Message-ID: <Z9ArueBi3cd3OLEo@pathway.suse.cz> (raw)
In-Reply-To: <911AD123-9CA6-405A-8D63-6F0806C12F84@gmail.com>
On Tue 2025-03-11 11:53:59, zhang warden wrote:
> > A single livepatch could modify more objects: vmlinux and several
> > modules. The metadata for each modified object are in "struct
> > klp_object". The related obect is currently identified only by obj->name.
> > And we could add more precision identification by setting
> > also "obj->srcversion" and/or "obj->build_id".
> >
>
> Yep, but how can we get the obj->srcversion? If we tring to store it
> in klp_object, the information should be carried when livepatch is being build.
> Otherwise, we don't know which srcversion is good to patch, isn't it?
I am not sure if I get the question correctly.
Anyway, struct klp_object must be defined in any livepatch, for example, see
/prace/kernel/linux/samples/livepatch/livepatch-sample.c
I guess that you are using kPatch. I am not sure how it initializes
these klp_patch, klp_object, and klp_func structures.
But it has to create struct klp_object for the livepatched module
and initialize at least .name, .func items.
The srcversion of the livepatched module can be read by modinfo,
for example:
# modinfo test_printf
filename: /lib/modules/6.13.0-default+/kernel/lib/test_printf.ko
license: GPL
description: Test cases for printf facility
author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
test: Y
srcversion: AF319FC942A3220645E7E99
depends:
intree: Y
name: test_printf
retpoline: Y
vermagic: 6.13.0-default+ SMP preempt mod_unload modversions
You need to teach kPatch to read the srcversion of the livepatched
module and set it in the related struct klp_object.
Best Regards,
Petr
next prev parent reply other threads:[~2025-03-11 12:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-07 3:12 [RFC] Add target module check before livepatch module loading zhang warden
2025-03-07 13:52 ` Petr Mladek
2025-03-10 2:22 ` zhang warden
2025-03-10 15:48 ` Petr Mladek
2025-03-11 3:53 ` zhang warden
2025-03-11 12:25 ` Petr Mladek [this message]
2025-03-12 3:17 ` zhang warden
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z9ArueBi3cd3OLEo@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=zhangwarden@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.