On Tue 2019-09-03 15:02:34, Miroslav Benes wrote:

On Mon, 2 Sep 2019, Joe Lawrence wrote:

quoted

On 9/2/19 12:13 PM, Miroslav Benes wrote:

quoted

quoted

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.

quoted

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.

quoted

  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:

  + 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?

Would it be better to discuss this in a separate room with
a whiteboard or paperboard?

Best Regards,
Petr