Re: [RFC PATCH 2/2] livepatch: Clear relocation targets on a module removal

[Joe Lawrence]

On 9/5/19 7:09 AM, Petr Mladek wrote:
> On Wed 2019-09-04 21:50:55, Josh Poimboeuf wrote:
> > On Wed, Sep 04, 2019 at 10:49:32AM +0200, Petr Mladek wrote:
> > > 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.
> >
> > Yes, and I like what I see.  Especially the removal of the .klp.arch
> > nastiness!
>
> Could we get rid of it?
>
> Is there any other way to get access to static variables
> and functions from the livepatched code?

Hi Petr,

I think the question is whether .klp (not-arch specific) relocations 
would be sufficient (without late module patching).  If it would a great 
simplification if those were all we needed.  I'm not 100% sure about 
this quite yet, but am hoping that is the case.

> > >        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.
> >
> > I'd like to hear more specific negatives about Joe's recent patches,
> > which IMO, are the best option we've discussed so far.
>
> I discussed this approach with our project manager. He was not much
> excited about this solution. His first idea was that it would block
> attaching USB devices. They are used by admins when taking care of
> the servers. And there might be other scenarios where a new module
> might need loading to solve some situation.
> > Customers understand Livepatching as a way how to secure system
> without immediate reboot and with minimal (invisible) effect
> on the workload. They might get pretty surprised when the system > suddenly blocks their "normal" workflow.

FWIW the complete blue-sky idea was that the package delivered to the 
customer (RPM, deb, whatever) would provide:

 - livepatch .ko, blacklists known vulnerable srcversions
 - updated .ko's for the blacklisted modules

The second part would maintain module loading workflow, albeit with a 
new set .ko files.

> As Miroslav said. No solution is perfect. We need to find the most
> acceptable compromise. It seems that you are more concerned about
> saving code, reducing complexity and risk. I am more concerned
> about user satisfaction.
>
> It is almost impossible to predict effects on user satisfaction
> because they have different workflow, use case, expectation,
> and tolerance.
>
> We could better estimate the technical side of each solution:
>
>     + implementation cost
>     + maintenance cost
>     + risks
>     + possible improvements and hardening
>     + user visible effects
>     + complication and limits with creating livepatches
>
>
>  From my POV, the most problematic is the arch-specific code.
> It is hard to maintain and we do not have it fully under
> control.
>
> And I do not believe that we could remove all arch specific code
> when we do not allow delayed livepatching of modules.

No doubt there will probably always be some arch-specific code, and even 
my blue-sky branch didn't move all that much.  But I think the idea 
could be a bigger simplification in terms of the mental model, should 
the solution be acceptable by criteria you mention above.

-- Joe