Received-SPF: pass (google.com: domain of linux-kernel+bounces-197414-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <a93e9121-4558-0cb7-224b-550738e45641@redhat.com>
Date: Fri, 31 May 2024 15:57:56 -0400
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Content-Language: en-US
To: Miroslav Benes <mbenes@suse.cz>
Cc: live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20200721161407.26806-1-joe.lawrence@redhat.com>
 <alpine.LSU.2.21.2405311319090.8344@pobox.suse.cz>
From: Joe Lawrence <joe.lawrence@redhat.com>
Subject: Re: [PATCH 0/2] livepatch: Add compiler optimization disclaimer/docs
In-Reply-To: <alpine.LSU.2.21.2405311319090.8344@pobox.suse.cz>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 5/31/24 07:23, Miroslav Benes wrote:
> Hi,
> 
> On Tue, 21 Jul 2020, Joe Lawrence wrote:
> 
>> In light of [PATCH] Revert "kbuild: use -flive-patching when
>> CONFIG_LIVEPATCH is enabled" [1], we should add some loud disclaimers
>> and explanation of the impact compiler optimizations have on
>> livepatching.
>>
>> The first commit provides detailed explanations and examples.  The list
>> was taken mostly from Miroslav's LPC talk a few years back.  This is a
>> bit rough, so corrections and additional suggestions welcome.  Expanding
>> upon the source-based patching approach would be helpful, too.
>>
>> The second commit adds a small README.rst file in the livepatch samples
>> directory pointing the reader to the doc introduced in the first commit.
>>
>> I didn't touch the livepatch kselftests yet as I'm still unsure about
>> how to best account for IPA here.  We could add the same README.rst
>> disclaimer here, too, but perhaps we have a chance to do something more.
>> Possibilities range from checking for renamed functions as part of their
>> build, or the selftest scripts, or even adding something to the kernel
>> API.  I think we'll have a better idea after reviewing the compiler
>> considerations doc.
> 
> thanks to Marcos for resurrecting this.
> 
> Joe, do you have an updated version by any chance? Some things have 
> changed since July 2020 so it calls for a new review. If there was an 
> improved version, it would be easier. If not, no problem at all.
> 

Yea, it's been a little while :) I don't have any newer version than
this one.  I can rebase,  apply all of the v1 suggestions, and see where
it stands.  LMK if you can think of any specifics that could be added.

For example, CONFIG_KERNEL_IBT will be driving some changes soon,
whether it be klp-convert for source-based patches or vmlinux.o binary
comparison for kpatch-build.

I can push a v2 with a few changes, but IIRC, last time we reviewed
this, it kinda begged the question of how someone is creating the
livepatch in the first place.  As long as we're fine holding that
thought for a while longer, this doc may still be useful by itself.

-- 
Joe