Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: [RFC PATCH 2/2] livepatch: Clear relocation targets on a module removal | From | Joe Lawrence <> | Date | Thu, 5 Sep 2019 07:39:35 -0400 |
| |
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
| ![\](/images/icornerr.gif) |