lkml.org 
[lkml]   [2019]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH 2/2] livepatch: Clear relocation targets on a module removal
From
Date
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

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