[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200415013117.rc7vlidmo4okzypl@treble>
Date: Tue, 14 Apr 2020 20:31:17 -0500
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Joe Lawrence <joe.lawrence@...hat.com>
Cc: live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
Jessica Yu <jeyu@...nel.org>
Subject: Re: [PATCH 0/7] livepatch,module: Remove .klp.arch and
module_disable_ro()
On Tue, Apr 14, 2020 at 08:57:15PM -0400, Joe Lawrence wrote:
> On 4/14/20 12:28 PM, Josh Poimboeuf wrote:
> > Better late than never, these patches add simplifications and
> > improvements for some issues Peter found six months ago, as part of his
> > non-writable text code (W^X) cleanups.
> >
> > Highlights:
> >
> > - Remove the livepatch arch-specific .klp.arch sections, which were used
> > to do paravirt patching and alternatives patching for livepatch
> > replacement code.
> >
> > - Add support for jump labels in patched code.
>
> Re: jump labels and late-module patching support...
>
> Is there still an issue of a non-exported static key defined in a
> to-be-patched module referenced and resolved via klp-relocation when the
> livepatch module is loaded first? (Basically the same case I asked Petr
> about in his split livepatch module PoC. [1])
>
> Or should we declare this an invalid klp-relocation use case and force the
> livepatch author to use static_key_enabled()?
>
> [1] https://lore.kernel.org/lkml/20200407205740.GA17061@redhat.com/
Right, if the static key lives in a module, then it's still not possible
for a jump label to use it. I added a check in kpatch-build to block
that case and suggest static_key_enabled() instead.
I don't know what the solution is, other than getting rid of late module
patching.
I confess I haven't looked at Petr's patches due to other distractions,
but I plan to soon.
--
Josh
Powered by blists - more mailing lists