Messages in this thread | | | Subject | Re: [RFC PATCH 2/2] livepatch: Clear relocation targets on a module removal | From | Joe Lawrence <> | Date | Wed, 4 Sep 2019 12:26:52 -0400 |
| |
On 9/4/19 4:49 AM, Petr Mladek wrote: > On Tue 2019-09-03 15:02:34, 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 >>> >>> 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. > > I wonder what is necessary for a productive discussion on Plumbers: >
Pre-planning this part of the miniconf is a great idea.
> + Josh would like to see what code can get removed when late > handling of modules gets removed. I think that it might be > partially visible from Joe's blue-sky patches. > > > + I would like to better understand the scope of the current > problems. It is about modifying code in the livepatch that > depends on position of the related code: > > + relocations are rather clear; we will need them anyway > to access non-public (static) API from the original code. > > + What are the other changes? > > + Do we use them in livepatches? How often? > > + How often new problematic features appear? > > + Would be possible to detect potential problems, for example > by comparing the code in the binary and in memory when > the module is loaded the normal way? > > + Would be possible to reset the livepatch code in memory > when the related module is unloaded and safe us half > of the troubles? > > > + It might be useful to prepare overview of the existing proposals > and agree on the positives and negatives. I am afraid that some > of them might depend on the customer base and > use cases. Sometimes we might not have enough information. > But it might be good to get on the same page where possible. > > Anyway, it might rule out some variants so that we could better > concentrate on the acceptable ones. Or come with yet another > proposal that would avoid the real blockers. > > > Any other ideas?
I'll just add to your list that late module patching introduces complexity for klp-convert / livepatch style relocation support. Without worrying about unloaded modules, I *think* klp-convert might already be able to handle relocations in special sections (altinsts, parainst, etc.).
I've put the current klp-convert patchset on top of the blue-sky branch to see if this indeed the case, but I'm not sure if I'll get through that experiment before LPC.
> > Would it be better to discuss this in a separate room with > a whiteboard or paperboard? >
Whiteboard would probably be ideal, but paper would work and be more transportable than the former.
-- Joe
| |