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:2.134 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site