[Ksummit-discuss] [CORE TOPIC] live patching

[Masami Hiramatsu]

On 2015/07/08 5:42, Jiri Kosina wrote:
> [ I was wondering whether to tag this "CORE TOPIC" or "TECH TOPIC", as I 
>   really see it on the bordeline; let's see ]
> 
> As people are probably aware, the basic infrastructure for live patching 
> of the kernel has been merged and there are still quite some loose ends to 
> tie up.
> 
> On top of original agreement by the two teams working at live kernel 
> patching at Red Hat and SUSE, there has been quite some feedback raised 
> during upstream review by people not being directly involved in the 
> development itself [1].
> 
> Tangentially related topics have been spawned in the discussion, namely:
> 
> - stack unwinding has so far been deemed purely debugging facility, with 
>   no correctness guarantees whatsoever. One of the possible aproaches to
>   improving the coverage of live patching infrastructure would assume
>   100% reliability of in-kernel stack unwinding.
> 
>   Is this something that should be pursued further? Especially opinions 
>   and comments from various arch maintainers would be welcome

Yeah, at least the live patch would be better to depend on a frame-pointer
to improve correctness...

> 
> - it would be beneficial for live patching if kernel threads could be 
>   cleaned up; currently it's a mess, with freezer points, signal handling 
>   etc. spewed randomly all over the main loop. Generalizing the API (such
>   as improving kthread_worker and migrating kthreads to use that) would 
>   be beneficial if there are no major objections. See my related TECH 
>   TOPIC submission
> 
> - Ingo proposed a "checkpoint"-based way for live patching, i.e. forcing 
>   all the processess out of kernel to serliaze on a well-defined execution
>   point, perform the patching, and resume the execution.

IMO, this is not acceptable especially for most of real-time scheduled tasks
which usually the mission critical systems require. And such systems are
the main target of the live patching feature I think, since those are
sometimes controlling civil infrastructure systems, like trains, plants,
factories and so on.

> 
>   I see several issues with this aproach, but Ingo seems to be really 
>   insisting on this to be the way to go.
> 
> I could give a short introduction to how the current in-kernel live 
> patching facility looks like and what are the things that are currently 
> missing (either because they were considered too controversial by some 
> (such as the stack unwinding reliability or lazy-migration) or because 
> they just have not been implemented yet) and hopefully create a basis for 
> a discussion that would result in more defined opinions on how this 
> facility should work to be widely acceptable.

I'd like to discuss about how to make better(prefer to live patching)
patches, and what kind of patches can not be applied too. If we can
make it clear, it is possible to make a tool to clarify.

Thank you,

> 
> Suggested attendance: folks working on live patching and anyone else 
> who's not directly involved, but has strong opinions on how things should 
> be done.
> 
> [1] http://lkml.kernel.org/r/20150220104418.GD25076@gmail.com
> 
> Thanks,
> 


-- 
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: masami.hiramatsu.pt at hitachi.com