linux-kernel - Re: [PATCH RFC 0/2] livepatch: patch creation tooling proposal

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: <20161110161053.heua3abuaekz4yy7@treble>
Date:   Thu, 10 Nov 2016 10:10:53 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Miroslav Benes <mbenes@...e.cz>
Cc:     live-patching@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Joerg Roedel <jroedel@...e.de>, jkosina@...e.cz,
        jeyu@...hat.com, pmladek@...e.cz
Subject: Re: [PATCH RFC 0/2] livepatch: patch creation tooling proposal

On Thu, Nov 10, 2016 at 04:48:33PM +0100, Miroslav Benes wrote:
> On Thu, 10 Nov 2016, Josh Poimboeuf wrote:
> 
> > On Thu, Oct 27, 2016 at 09:35:48AM -0500, Josh Poimboeuf wrote:
> > > So here's my proposal: use the existing kernel build infrastructure.  If
> > > klp relocations are needed, manually specify them with a new
> > > klp_module_reloc struct and corresponding KLP_MODULE_RELOC macro.  Then
> > > run a post-processing tool called klp-convert which converts those
> > > klp_module_reloc structs into the sections, relocations, and symbols
> > > needed by the klp runtime code.
> > 
> > I think the biggest blocker for this approach is detecting gcc
> > optimizations which break function ABI, i.e. Miroslav's presentation:
> > 
> >   http://www.linuxplumbersconf.org/2016/ocw//system/presentations/3573/original/pres_gcc.pdf
> > 
> > Right now we have no way of finding all such cases.
> > 
> > I think our options are:
> > 
> > 1) Find a way for gcc to report when function ABI has been broken;
> 
> This is the one I'd like to pursue in parallel to 3). But it is 
> going to be long way I imagine.

Yes, the gcc folks I've talked to seem to agree.

> > 2) Disable all gcc optimizations which can break function ABI.  Not sure
> >    if this is even possible, but if so, we'd need to quantify the
> >    performance impact.  (Note we might be able to leave some options
> >    enabled if they result in a function name change (e.g.,
> >    -fpartial-inlining, -fipa-sra, -fipa-cp)); or
> 
> I don't think this is possible. I mean technically possible, because 
> I'm almost sure some optimizations cannot be disabled easily. And also 
> performance-wise. It could have a serious impact on the kernel with 
> CONFIG_LIVEPATCH enabled.
> 
> I consider this option a last resort.

I have some doubts about whether it would noticeably impact performance.
As far as I can tell these optimizations are quite rare.

FWIW, I've asked some gcc folks about the feasibility of something like
a '-fpreserve-function-abi' option.  But I'm not holding my breath.  It
seems like a hard problem.

> > 3) Stay with the status quo (kpatch-build?), since it has detection of
> >    such optimizations "built in".
> 
> Also possible. We could explore the usability of Joerg's asmtool for the 
> purpose.
> 
> https://github.com/joergroedel/asmtool
> 
> It could be useful even if for the detection of changed functions.
> 
> > Does anybody want to take ownership of this patch set and/or try to
> > explore the options further?  I don't have any more bandwidth right now
> > (mainly due to the consistency model and porting objtool to DWARF).
> 
> Sure. I can take it. I tried to write a similar tool, I saw kpatch-build 
> sources and have a clue how it all works. On the other hand, no promises 
> about a timeline.

Great, thanks!  I think your experiences with the gcc optimizations and
with the various patch building tools make you a great candidate for
this.

-- 
Josh