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: <20240905163008.kjlavrw6k6eb6aqu@treble>
Date: Thu, 5 Sep 2024 09:30:08 -0700
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: zhang warden <zhangwarden@...il.com>
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 Thu, Sep 05, 2024 at 10:03:52PM +0800, zhang warden wrote:
> >>Here I can give you an example.
> We are going to fix a problem of io_uring.
> Our team made a livepatch of io_sq_offload_create.
> This livepatch module is deployed to some running servers.
> 
> Then, another team make some change to the same function and deployed it to the same cluster.
> 
> Finally, they found that there are some livepatch module modifying the same function io_sq_offload_create. But none of them can tell which version of io_sq_offload_create is now exactly running in the system.
> 
> We can only use crash to debug /proc/kcore to see if we can get more information from the kcore.
> 
> If livepatch can tell which version of the function is now running or going to run, it will be very useful.
> 
> >>>>>>
> What's more, the scenario we easily face is that for the confidential environment, the system maintenance mainly depends on SREs. Different team may do bug fix or performance optimization to kernel function. 
> 
> Here usually some SREs comes to me and ask me how to make sure which version is now actually active because tow teams make tow livepatch modules, both of them make changes to one function. 
> 
> He wants to know if his system is under risk, he want the system run the right version of the function because one module is a bug fix and the other is just a performance optimization module, at this time, the bug fix version is much more important. dmesg is too long, he find it hard to find out the patch order from dmesg.
> 
> With this patch, he can just cat /sys/kernel/livepatch/<module>/<object>/<function>/using and get his answer.

Thanks for the details, and sorry if I missed it before.  This would
have been helpful to have in the cover letter.

But again I want to stress that livepatching should be done with care.
Having different teams applying patches without coordination is not
recommended.  The teams' processes and/or tooling really need to be
improved.

> > Have you considered other solutions,
> > like more organized patch management in user space?
> 
> User space solutions seems unreliable. What we need is just the enabling version of target function. The order of livepatch module enable mainly from dmesg, which is easily flush away or being cleaned.

journalctl -b ?

> If we use an user space program to maintain the information of patch order, once the program is killed, the information is loss either.

Store the state in a file in /var/run?

-- 
Josh