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.
[1] https://lore.kernel.org/lkml/696262e997359666afa053fe7d1a9fb2bb373964.1595010490.git.jpoimboe@redhat.com/
Joe Lawrence (2):
docs/livepatch: Add new compiler considerations doc
samples/livepatch: Add README.rst disclaimer
.../livepatch/compiler-considerations.rst | 220 ++++++++++++++++++
Documentation/livepatch/index.rst | 1 +
Documentation/livepatch/livepatch.rst | 7 +
samples/livepatch/README.rst | 15 ++
4 files changed, 243 insertions(+)
create mode 100644 Documentation/livepatch/compiler-considerations.rst
create mode 100644 samples/livepatch/README.rst
--
2.21.3
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.
Miroslav
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
Hi,
On Fri, 31 May 2024, Joe Lawrence wrote:
> 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.
I will walk through the patches first to see if there is something which
can/should be changed given the development since then.
> 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.
True.
> 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.
If I remember correctly, the conclusion was that this doc was beneficial
on its own.
Miroslav