linux-kernel - Re: [PATCH 0/8] livepatch: klp-convert tool

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20171020142009.hqnfuklf3l22noz2@treble>
Date:   Fri, 20 Oct 2017 09:20:09 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Torsten Duwe <duwe@....de>
Cc:     Miroslav Benes <mbenes@...e.cz>, Joao Moreira <jmoreira@...e.de>,
        live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
        pmladek@...e.com, jikos@...e.cz, nstange@...e.de, jroedel@...e.de,
        matz@...e.de, khlebnikov@...dex-team.ru, jeyu@...nel.org
Subject: Re: [PATCH 0/8] livepatch: klp-convert tool

On Fri, Oct 20, 2017 at 03:44:12PM +0200, Torsten Duwe wrote:
> 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:
> > > 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 :-(

Yes, you do have to patch the caller in that case.  But kpatch-build
detects that the caller changed as well, so both functions get patched
and it's not a problem.

And I don't remember ever seeing more than one caller for such a case.
At least it's never been a problem so far.

-- 
Josh