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:   Thu, 20 Dec 2018 09:33:05 +0100 (CET)
From:   Miroslav Benes <mbenes@...e.cz>
To:     Jiri Kosina <jikos@...nel.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>
cc:     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 Wed, 19 Dec 2018, Jiri Kosina wrote:

> On Wed, 19 Dec 2018, Josh Poimboeuf wrote:
> 
> > Also the commit message needs an analysis of the performance impacts.
> 
> Agreed. Especially as it's expected (*) to be completely in the noise 
> particularly for the kernel, it'd be good to have that documented in the 
> changelog.
> 
> (*) actually measured already for some subset of the IPA optimizations

Ok, we can do that. I don't expect the results to be different from the 
last measurement as Jiri mentions. The sets of disabled optimizations are 
similar.

I'll add it to v2.

On Wed, 19 Dec 2018, Jiri Kosina wrote:

> On Wed, 19 Dec 2018, Josh Poimboeuf wrote:
> 
> > > > This option only makes sense for source-based patch generation, so isn't 
> > > > it a bit premature to make this change without proper source-based patch 
> > > > tooling?
> > > 
> > > The reality is though that before the full-fledged patch tooling exists, 
> > > people are actually already writing livepatches by hand, so this option is 
> > > useful for them.
> > 
> > Fair enough.

Yes, that was the reason I sent it. It would not make sense to wait for 
the tooling in this case, because -flive-patching is useful even now, 
since there is a way to prepare livepatches without any tooling.

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

Miroslav