Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 11 Apr 2023 21:17:52 -0700
From:   Josh Poimboeuf <jpoimboe@kernel.org>
To:     Mark Rutland <mark.rutland@arm.com>
Cc:     "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>,
        jpoimboe@redhat.com, peterz@infradead.org, chenzhongjin@huawei.com,
        broonie@kernel.org, nobuta.keiya@fujitsu.com,
        sjitindarsingh@gmail.com, catalin.marinas@arm.com, will@kernel.org,
        jamorris@linux.microsoft.com, linux-arm-kernel@lists.infradead.org,
        live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame
 pointer validation
Message-ID: <20230412041752.i4raswvrnacnjjgy@treble>
References: <0337266cf19f4c98388e3f6d09f590d9de258dc7>
 <20230202074036.507249-1-madvenka@linux.microsoft.com>
 <ZByJmnc/XDcqQwoZ@FVFF77S0Q05N.cambridge.arm.com>
 <054ce0d6-70f0-b834-d4e5-1049c8df7492@linux.microsoft.com>
 <ZDVft9kysWMfTiZW@FVFF77S0Q05N>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <ZDVft9kysWMfTiZW@FVFF77S0Q05N>
Precedence: bulk

On Tue, Apr 11, 2023 at 02:25:11PM +0100, Mark Rutland wrote:
> > By your own argument, we cannot rely on the compiler as compiler implementations,
> > optimization strategies, etc can change in ways that are incompatible with any
> > livepatch implementation.
> 
> That's not quite my argument.
> 
> My argument is that if we assume some set of properties that compiler folk
> never agreed to (and were never made aware of), then compiler folk are well
> within their rights to change the compiler such that it doesn't provide those
> properties, and it's very likely that such expectation will be broken. We've
> seen that happen before (e.g. with jump tables).
> 
> Consequently I think we should be working with compiler folk to agree upon some
> solution, where compiler folk will actually try to maintain the properties we
> depend upon (and e.g. they could have tests for). That sort of co-design has
> worked well so far (e.g. with things like kCFI).
> 
> Ideally we'd have people in the same room to have a discussion (e.g. at LPC).

That was the goal of my talk at LPC last year:

  https://lpc.events/event/16/contributions/1392/

We discussed having the compiler annotate the tricky bits of control
flow, mainly jump tables and noreturns.  It's still on my TODO list to
prototype that.

Another alternative which has been suggested in the past by Indu and
others is for objtool to use DWARF/sframe as an input to help guide it
through the tricky bits.

That seems more fragile -- as Madhavan mentioned, GCC-generated DWARF
has some reliability issues -- and also defeats some of the benefits of
reverse-engineering in the first place (we've found many compiler bugs
and other surprising kernel-compiler interactions over the years).

Objtool's understanding of the control flow graph has been really
valuable for reasons beyond live patching (e.g., noinstr and uaccess
validation), it's definitely worth finding a way to make that more
sustainable.

-- 
Josh