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 -- 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
