linux-kernel - Re: [PATCH v4 2/2] livepatch: Add using attribute to klp

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: <AAD198C9-210E-4E31-8FD7-270C39A974A8@gmail.com>
Date: Wed, 4 Sep 2024 14:34:44 +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,
 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 12:48, Josh Poimboeuf <jpoimboe@...nel.org> wrote:
> 
> On Wed, Aug 28, 2024 at 10:23:50AM +0800, Wardenjohn wrote:
>> One system may contains more than one livepatch module. We can see
>> which patch is enabled. If some patches applied to one system
>> modifing the same function, livepatch will use the function enabled
>> on top of the function stack. However, we can not excatly know
>> which function of which patch is now enabling.
>> 
>> This patch introduce one sysfs attribute of "using" to klp_func.
>> For example, if there are serval patches  make changes to function
>> "meminfo_proc_show", the attribute "enabled" of all the patch is 1.
>> With this attribute, we can easily know the version enabling belongs
>> to which patch.
>> 
>> The "using" is set as three state. 0 is disabled, it means that this
>> version of function is not used. 1 is running, it means that this
>> version of function is now running. -1 is unknown, it means that
>> this version of function is under transition, some task is still
>> chaning their running version of this function.
> 
> I'm missing how this is actually useful in the real world.  It feels
> like a solution in search of a problem.  And it adds significant
> maintenance burden.  Why?
> 
> Do you not have any control over what order your patches are applied?
> If not, that sounds dangerous and you have much bigger problems.
> 
> This "problem" needs to be managed in user space.
> 
> -- 
> Josh

Hi, Josh.

First, introducing feature "using" is just a state of one klp_function is using or not in the system.
I think this state will not bring significant maintenance burden, right?

And then, this feature can tell user that which function is now running in this system. As we know, livepatch enable many patches for one function, and the stack top function of target function is the "using" function. Here will bring us some questions: 
1. Since we patch some patches to one function, which version of this function A is my system exactly now using? 
2. One patch may contains many function fixes, the "using" version of target function belongs to which patch now? 
Livepatch now cannot tell us this information, although livepatch can do it.

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.

A real case I met have been shown in the previous mail to explain the use in real world.

At the process I introduce this feature, we found that the function of klp_find_ops can be optimized. If we can move klp_ops structure into klp_func, we don't need to maintain one global list again. And if we want to find an klp_ops, we just need to get the klp_func (which we will already have). This will be a nice efficiency improvement.

Regards.
Wardenjohn.