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: <alpine.LNX.2.00.1611101640540.12314@pobox.suse.cz>
Date:   Thu, 10 Nov 2016 16:48:33 +0100 (CET)
From:   Miroslav Benes <mbenes@...e.cz>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
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, 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.

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

Miroslav