lkml.org 
[lkml]   [2019]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 2/2] livepatch: Clear relocation targets on a module removal
On Tue, Sep 03, 2019 at 03:02:34PM +0200, Miroslav Benes wrote:
> On Mon, 2 Sep 2019, Joe Lawrence wrote:
>
> > On 9/2/19 12:13 PM, Miroslav Benes wrote:
> > >> I can easily foresee more problems like those in the future. Going
> > >> forward we have to always keep track of which special sections are
> > >> needed for which architectures. Those special sections can change over
> > >> time, or can simply be overlooked for a given architecture. It's
> > >> fragile.
> > >
> > > Indeed. It bothers me a lot. Even x86 "port" is not feature complete in
> > > this regard (jump labels, alternatives,...) and who knows what lurks in
> > > the corners of the other architectures we support.
> > >
> > > So it is in itself reason enough to do something about late module
> > > patching.
> > >
> >
> > Hi Miroslav,
> >
> > I was tinkering with the "blue-sky" ideas that I mentioned to Josh the other
> > day.
>
> > I dunno if you had a chance to look at what removing that code looks
> > like, but I can continue to flesh out that idea if it looks interesting:
>
> Unfortunately no and I don't think I'll come up with something useful
> before LPC, so anything is really welcome.
>
> >
> > https://github.com/joe-lawrence/linux/tree/blue-sky

I like this a lot.

> > A full demo would require packaging up replacement .ko's with a livepatch, as
> > well as "blacklisting" those deprecated .kos, etc. But that's all I had time
> > to cook up last week before our holiday weekend here.
>
> Frankly, I'm not sure about this approach. I'm kind of torn. The current
> solution is far from ideal, but I'm not excited about the other options
> either. It seems like the choice is basically between "general but
> technically complicated fragile solution with nontrivial maintenance
> burden", or "something safer and maybe cleaner, but limiting for
> users/distros". Of course it depends on whether the limitation is even
> real and how big it is. Unfortunately we cannot quantify it much and that
> is probably why our opinions (in the email thread) differ.

How would this option be "limiting for users/distros"? If the packaging
part of the solution is done correctly then I don't see how it would be
limiting.

--
Josh

\
 
 \ /
  Last update: 2019-09-05 04:33    [W:0.143 / U:1.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site