Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 25 Apr 2019 10:26:28 -0500
From:   Josh Poimboeuf <jpoimboe@redhat.com>
To:     live-patching@vger.kernel.org
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Mark Rutland <mark.rutland@arm.com>,
        linux-kernel@vger.kernel.org
Subject: Livepatch vs LTO
Message-ID: <20190425152628.ogk4woi3omeocwly@treble>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
User-Agent: NeoMutt/20180716
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi all,

On IRC, Peter expressed some concern about -flive-patching, specifically
that the flag isn't compatible with LTO.

The upstream kernel currently doesn't support LTO, but Android is using
it with LLVM:

  https://source.android.com/devices/tech/debug/kcfi

And there seems to be progress being made in that direction for
upstream.

Live patching has at least the following issues with LTO:

- For source-based patch generation (klp-convert and friends), the GCC
  manual says that -flive-patching is incompatible with LTO.  Does
  anybody know if that's a hard incompatibility, or can it be fixed?

  Also, what about the performance implications of this flag with LTO?
  Might they become more pronounced?

  Also I wonder if -fdump-ipa-clones works with LTO?

  I also wonder about the future of source-based patch generation with
  LLVM.  Will it also have -flive-patching and -fdump-ipa-clones flags?

- For binary-based patch generation (kpatch-build), we currently diff
  objects at a per-compilation-unit level.  That would have to be
  changed to work on vmlinux.o instead.

- Objtool would also have to be changed to work on vmlinux.o.  It's
  currently not optimized for large files, and the per-.o whitelisting
  would need to be fixed.  And there may be other issues lurking.

Also, thinking about objtool in this context has given me another idea,
which might allow us to get rid of the use of -flive-patching and
-fdump-ipa-clones altogether (which are both nasty and way too
compiler-dependent):

Since objtool is already reading every function in the kernel, it could
create a checksum associated with each function, based on all the
instructions (both within the function and any alternatives or other
special sections it relies on).  The function checksums could be written
to a file.

Then, when a patch file is applied and the kernel rebuilt, the checksum
files could be compared to determine exactly which functions have
changed at a binary level.

Thoughts?  Any reasons why that wouldn't work?

And, if we wanted to take the idea even further, objtool could have the
ability to write the changed functions to a new object file.  Voila, we
now pretty much have kpatch-build :-)  (Though whether this is better
than source-based patch generation is certainly an open question.)

-- 
Josh