From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751826AbdJTNoO (ORCPT ); Fri, 20 Oct 2017 09:44:14 -0400 Received: from verein.lst.de ([213.95.11.211]:48938 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750943AbdJTNoN (ORCPT ); Fri, 20 Oct 2017 09:44:13 -0400 Date: Fri, 20 Oct 2017 15:44:12 +0200 From: Torsten Duwe To: Josh Poimboeuf Cc: Miroslav Benes , Joao Moreira , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, pmladek@suse.com, jikos@suse.cz, nstange@suse.de, jroedel@suse.de, matz@suse.de, khlebnikov@yandex-team.ru, jeyu@kernel.org Subject: Re: [PATCH 0/8] livepatch: klp-convert tool Message-ID: <20171020134412.GA28905@lst.de> References: <20171011024615.y55lwbgpgo6b5dll@treble> <14124e34-04f7-950e-72fb-64f13e62f57e@suse.de> <20171019130146.uxjuhgn2t3yavgz2@treble> <20171019140338.pngwewyzllaw2wu5@treble> <20171019151522.5ih3egvzr3wm3h7r@treble> <20171020124432.GB20306@lst.de> <20171020132432.majphjzzfrbcrdos@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171020132432.majphjzzfrbcrdos@treble> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 20, 2017 at 08:24:32AM -0500, Josh Poimboeuf wrote: > On Fri, Oct 20, 2017 at 02:44:32PM +0200, Torsten Duwe wrote: > > On Thu, Oct 19, 2017 at 06:00:54PM +0200, Miroslav Benes wrote: > > > On Thu, 19 Oct 2017, Josh Poimboeuf wrote: > > > > > > > > Sounds nice, though I wonder what the obstacles are? > > > > > > Those GCC optimizations you mentioned below and which I didn't connect to > > > klp-convert itself. > > > > I have a bad feeling about the IPA stuff in general. An obj-based approach > > is cool in a way that it still works, and is sure to work, if the IPA > > assumptions that led to the optimisations still hold, but as soon as they > > break, you're screwed big time. > > Huh? The obj-based approach (e.g., kpatch, bin-diff) inherently detects > such changes. Or am I misunderstanding? If so, please elaborate. If e.g. the old callee does not use a caller-saved reg, neither does the new code, there is no reason to actually save it. IPA will detect this and spare the reg save/restore. If now by any coincidence the new function needs that register, what can you do? Patch all callers as well? You'll likely end up with a far-too-big live patch or by coding something in assembler :-( > > For -fpatchable-function-entries I switched > > off IPA-RA, as especially on RISC there's _nothing_ you can do between > > functions without at least one scratch reg. But for live patching, I'd like > > the kernel to be compiled in the first place with 100% ABI adherence, IOW > > all IPA optimisations turned off. Does anyone have numbers on the performance > > impact? > > I agree that would be the best option. I'm glad to hear this!-) > > For example, if the patched functions and the fixes meet its criteria, you > > could use CMBC (http://www.cprover.org/cbmc/) to _prove_ that the live patch > > changes exactly what you claim to, and nothing else. > > Can it also prove that the patch is applied in a safe manner? I assume this strongly depends on the test cases you build around it. OTOH the more code you include in the test, the more likely you'll violate the cbmc preconditions. So I guess the simple answer is "no". But this might change in the future. Torsten