On Mon, Nov 24, 2014 at 12:13:20PM +0100, Thomas Gleixner wrote: > On Thu, 20 Nov 2014, Seth Jennings wrote: > > This commit introduces code for the live patching core. It implements > > an ftrace-based mechanism and kernel interface for doing live patching > > of kernel and kernel module functions. > > > > It represents the greatest common functionality set between kpatch and > > kgraft and can accept patches built using either method. > > > > This first version does not implement any consistency mechanism that > > ensures that old and new code do not run together. In practice, ~90% of > > CVEs are safe to apply in this way, since they simply add a conditional > > check. However, any function change that can not execute safely with > > the old version of the function can _not_ be safely applied in this > > version. > > To be honest this sounds frightening. The risky part of live patching is patch analysis and creation. If the user isn't careful with their analysis, they're playing with fire. We'll be documenting the patch analysis steps, so that if you carefully follow the steps, it's safe. But that should generally be the role of the distribution. > How is determined whether a change can be applied w/o a consistency > mechanism or not? The following are not safe without consistency mechanisms: - function prototype changes - data structure changes - data semantic changes: changes to how functions interact with a data structure, e.g. locking order We'll be adding the consistency mechanisms later to enable function and data consistency. But even then you have to be very careful. -- Josh -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
