linux-kernel - Re: [PATCH] kbuild: use -flive-patching when CONFIG

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]

Date:   Fri, 21 Dec 2018 10:45:49 +0100 (CET)
From:   Miroslav Benes <mbenes@...e.cz>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
cc:     Jiri Kosina <jikos@...nel.org>, yamada.masahiro@...ionext.com,
        michal.lkml@...kovi.net, jeyu@...nel.org, pmladek@...e.com,
        linux-kbuild@...r.kernel.org, live-patching@...r.kernel.org,
        linux-kernel@...r.kernel.org, Joao Moreira <jmoreira@...e.de>
Subject: Re: [PATCH] kbuild: use -flive-patching when CONFIG_LIVEPATCH is
 enabled

On Thu, 20 Dec 2018, Josh Poimboeuf wrote:

> On Thu, Dec 20, 2018 at 09:33:05AM +0100, Miroslav Benes wrote:
> > > > Though, upstream, almost everybody seems to use kpatch-build, for which
> > > > this patch doesn't help.  And people will continue to do so until we
> > > > have decent source-based tooling.  Will the klp-convert patches be
> > > > revived soon?
> > >
> > > Let me add Joao, who's working on that.
> > > 
> > > Joao, I think you had something basically ready for upstream exposure, 
> > > right?
> > 
> > I think that when Joao posted it a long time ago, the conclusion was that 
> > it would be better to wait for the source-based tooling and have the 
> > complete solution. I may misremember though.
> > 
> > If Josh thinks that it would be acceptable to have klp-convert merged even 
> > without the tooling, I'm all for it.
> > 
> > We're about to start using it at SUSE and staying close to upstream would 
> > definitely be better.
> 
> A complete toolchain should definitely be the end goal.
> 
> But as a usable first step, only *some* of the tooling is required,
> since some of the steps can be done manually, right?
> 
> So starting out, for something usable, I believe the following would be
> the bare minimum:
> 
>   * -flive-patching
> 
>   * The analysis tool which analyzes the -fdump-ipa-clones files
> 
>   * klp-convert
> 
>   * Documentation describing the end-to-end patch creation process,
>     including the manual steps and how to use the above tools
> 
> Did I miss anything?
> 
> Then over time we can fill in the gaps (manual steps) with automation.

Agreed.

Miroslav