Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751969AbbBUUKh (ORCPT ); Sat, 21 Feb 2015 15:10:37 -0500 Received: from cantor2.suse.de ([195.135.220.15]:48723 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751671AbbBUUKg (ORCPT ); Sat, 21 Feb 2015 15:10:36 -0500 Date: Sat, 21 Feb 2015 21:10:33 +0100 (CET) From: Jiri Kosina To: Ingo Molnar cc: Vojtech Pavlik , Josh Poimboeuf , Peter Zijlstra , Andrew Morton , Ingo Molnar , Seth Jennings , linux-kernel@vger.kernel.org, Linus Torvalds Subject: Re: live patching design (was: Re: [PATCH 1/3] sched: add sched_task_call()) In-Reply-To: <20150221194840.GA10126@gmail.com> Message-ID: References: <20150220095003.GA23506@gmail.com> <20150220104418.GD25076@gmail.com> <20150220194901.GB3603@gmail.com> <20150220214613.GA21598@suse.com> <20150221181852.GA8406@gmail.com> <20150221191607.GA9534@gmail.com> <20150221194840.GA10126@gmail.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3136 Lines: 77 On Sat, 21 Feb 2015, Ingo Molnar wrote: > > I see the difference, but I am afraid you are simplifying > > the situation a litle bit too much. > > > > There will always be properties of patches that will make > > them unapplicable in a "live patching" way by design. > > Think of data structure layout changes (*). > > Yes. The (*) note described that it's actually in theory possible, but the price to pay is very high. So it's possible to write a patch that does this, and have it use a different consistency model, which would take care of data structure layout change (and the fact that this particular consistency model is very expensive, would be a clear fact). Your "simple one-method-to-rule-them-all aproach" is not sufficient for this. Even such a stretched case doesn't justify existency of consistency models for you? > > Or think of kernel that has some 3rd party vendor module loaded, and > > this module spawning a ktrehad that is not capable of parking itself. > > The kernel will refuse to live patch until the module is fixed. It is a > win by any measure. Depends on your point of view. If you are an administrator of the vulnerable system, you have no to very little clue why patching your system is not possible (and what you should to to have it fixed in the coming days, before your system is taken down by attackers, for example), and would be really sad to be forced to run with unpatched system. I see your point that this would be a good lever we'd have to 3rd party vendors, but OTOH we'd be taking OS users as hostages in some sense. > > Or think of patching __notrace__ functions. > > Why would __notrace__ functions be a problem in the 'simple' method? > Live patching with this method will work even if ftrace is not built in, > we can just patch out the function in the simplest possible fashion, > because we do it atomically and don't have to worry about per task > 'transition state' - like kGraft does. > > It's a massive simplification and there's no need to rely on ftrace's > mcount trick. (Sorry Steve!) This would indeed be possible iff we take the "global synchronizing point" aproach you are proposing. Still technicalities to be solved (what happens if you are patching that already has ftrace on it, etc), but probably nothing principal. > > So it's not black and white, it's really a rather philosophical > > question where to draw the line (and make sure that everyone is aware > > of where the line is and what it means). > > Out of the three examples you mentioned, two are actually an advantage > to begin with - so I'd suggest you stop condescending me ... Ugh, if you feel my e-mails like attempts to condescend you, I am really surprised; I thought we are discussing technical details. If you feel otherwise, we should probably just stop discussing then. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/