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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171019130146.uxjuhgn2t3yavgz2@treble>
Date:   Thu, 19 Oct 2017 08:01:46 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Joao Moreira <jmoreira@...e.de>
Cc:     Miroslav Benes <mbenes@...e.cz>, live-patching@...r.kernel.org,
        linux-kernel@...r.kernel.org, mmarek@...e.cz, 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 Wed, Oct 11, 2017 at 09:42:09AM -0300, Joao Moreira wrote:
> > Sounds good!  For klp-convert to be successful, we really need a
> > strategy for dealing with such optimizations.  I'm thinking that a
> > '-fpreserve-function-abi' flag would be the cleanest way to handle it.
> > 
> > If we don't have a strategy for dealing with optimizations, then we may
> > instead need to go with a binary diff-based tool like kpatch-build.
> 
> I'm currently looking into binary diff-based solutions to deal with this
> problem. My plan is to submit a second patch set once I have it functional
> and land both things (klp-convert and bin-diff) in two different steps.

Instead of having multiple approaches, I'd strongly prefer that we
converge on a single in-tree approach that works for everybody.

(Whether that will be source-based like klp-convert or binary-based like
kpatch-build, I don't know.)

BTW, what is bin-diff?  Have you seen kpatch-build?

> Is there any issue with following this schedule? Meaning, do you guys still
> plan on reviewing this patch set or do you prefer me to do something
> differently in terms of approach?

IMO, klp-convert will only be useful if we have a realistic strategy for
dealing with GCC optimizations.  So I'd say we should follow through on
that with the compiler folks before spending too much more time on it.

-- 
Josh