Re: [RFC PATCH 0/2] kpatch: dynamic kernel patching

[Jiri Kosina]

On Fri, 16 May 2014, Steven Rostedt wrote:

> > With lazy-switching implemented in kgraft, this can never happen.
> > 
> > So I'd like to ask for a little bit more explanation why you think the 
> > stop_machine()-based patching provides more sanity/consistency assurance 
> > than the lazy switching we're doing.
> 
> Here's what I'm more concerned with. With "lazy" switching you can have
> two tasks running two different versions of bar(). What happens if the
> locking of data within bar changes? Say the data was protected
> incorrectly with mutex(X) and you now need to protect it with mutex(Y).
> 
> With stop machine, you can make sure everyone is out of bar() and all
> tasks will use the same mutex to access the data. But with a lazy
> approach, one task can be protecting the data with mutex(X) and the
> other with mutex(Y) causing both tasks to be accessing the data at the
> same time.
> 
> *That* is what I'm more concerned about.

That's true, and we come back to what has been said at the very beginning 
for both aproaches -- you can't really get away without manual human 
inspection of the patches that are being applied.

The case you have outlined is indeed problematic for the "lazy switching" 
aproach, and can be worked around (interim function, which takes both 
mutexes in well defined order, for example).

You can construct a broken locking scenario for stop_machine() aproach as 
well -- consider a case when you are exchaing a function which changes the 
locking order of two locks/mutexes. How do you deal with the rest of the 
code where the locks are being acquired, but not through the functions 
you've exchanged?

So again -- there is no disagreement, I believe, about the fact that "live 
patches" can't be reliably auto-generated, and human inspection will 
always be necessary. Given the intended use-case (serious CVEs mostly, 
handled by distro vendors), this is fine.

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/