Message-ID: <de73b9c6-fa57-8893-d7ae-5256bbb603b5@redhat.com>
Date:   Thu, 5 Sep 2019 07:39:35 -0400
From:   Joe Lawrence <joe.lawrence@...hat.com>
To:     Petr Mladek <pmladek@...e.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     jikos@...nel.org, Miroslav Benes <mbenes@...e.cz>,
        linux-kernel@...r.kernel.org, live-patching@...r.kernel.org
Subject: Re: [RFC PATCH 2/2] livepatch: Clear relocation targets on a module
 removal

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

Powered by blists - more mailing lists