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] [thread-next>] [day] [month] [year] [list]
Message-Id: <1517E547-55C1-4962-9B6F-D9723FEC2BE0@gmail.com>
Date: Wed, 4 Sep 2024 15:30:22 +0800
From: zhang warden <zhangwarden@...il.com>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Miroslav Benes <mbenes@...e.cz>,
 Jiri Kosina <jikos@...nel.org>,
 Petr Mladek <pmladek@...e.com>,
 Joe Lawrence <joe.lawrence@...hat.com>,
 live-patching@...r.kernel.org,
 LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 2/2] livepatch: Add using attribute to klp_func for
 using function show



> On Sep 4, 2024, at 15:14, Josh Poimboeuf <jpoimboe@...nel.org> wrote:
> 
> On Wed, Sep 04, 2024 at 02:34:44PM +0800, zhang warden wrote:
>> In the scenario where multiple people work together to maintain the
>> same system, or a long time running system, the patch sets will
>> inevitably be cumulative. I think kernel can maintain and tell user
>> this most accurate information by one sysfs interface.
> 
> If there are multiple people applying patches independently from each
> other (to the same function even!), you are playing with fire, as there
> could easily be implicit dependencies and conflicts between the patches.
> 
> 
Yep, I agree with you. This is not a good practice.

But we can work further, livepatch can tell which function is now running. This feature can do more than that.

Afterall, users alway want to know if their newly patched function successfully enabled and using to fix the bug-existed kernel function.

With this feature, user can confirm their patch is successfully running instead of using crash to look into /proc/kcore to make sure this function is running now. (I always use this method to check my function patched ... lol).

And I think further, if we use kpatch-build[1], `kpatch list` can not only tell us which patch is enabled, but also tell us the relationship between running function and patched module.
I think this is an exciting feature...

[1] https://github.com/dynup/kpatch.git


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ