On Tue, Jul 14, 2015 at 12:04:56AM +0200, Jiri Kosina wrote:
> On Mon, 13 Jul 2015, Josh Poimboeuf wrote:
>
> > > As a distro vendor, you definitely want to ship this as a single
> > > livepatch, but you absolutely don't want it to cause force modprobing of
> > > every affected network driver on all systems that install that livepatch.
> >
> > That example is pretty much the worst case scenario.
>
> I've pulled it completely out of the air, but I am currently far from
> claiming it impossible. It's not just network drivers / netdev API. We're
> in similar situation is with filesystems / vfs, pretty much anything /
> {mm, sysfs}, etc.
>
> So I would really like to avoid ignoring such scenarios. Let's try to be
> as general as possible.
>
> > But how likely is it really? Have you encountered anything like that
> > with SLES?
>
> That's hard to say for me immediately; definitely not with our live
> patching offering, but that's been there only for relatively short time so
> far. I'll try to do some more sophisticated analysis of the kernel patches
> tomorrow, to see if I am able to find some instances of this pattern.
Thanks. I think some specifics would really help. I'll try to do the
same.
> [ ... snip ... ]
> > I'd say the two hairiest parts of livepatch are the module notifier code
> > and the relocation code. We could get rid of both of them if we didn't
> > need to patch unloaded modules. That would make the livepatch code 100%
> > architecture-independent and much cleaner.
>
> Relocation code would be useful also in cases when you're patching a
> module code that's using non-exported symbols (from the same module) and
> you'd like to avoid either patch code explosion (and code duplication) or
> ugly per-patch kallsyms-lookup code, right?
>
> And the same holds for patching in-core code using non-exported symbols.
Right, we still want to do relocation of unexported symbols. The
proposal is to have the kernel module loader code do it instead of us.
Also, it's late and this is still a half-formed thought, but... in the
case of building livepatch modules using kbuild (rather than a more
heavyweight tool like kpatch-build) I think it might also make it
possible to have a C macro which allows you to specify unexported symbol
addresses directly from the patch code source. That could be a big win
for the kbuild approach to building patch modules. Need to think about
that some more.
> > > At the same time, you really do want to make sure that once the networking
> > > driver gets eventually modprobed any time in the future (for example
> > > network device is hotplugged), it gets patched upon load.
> >
> > I suppose patched versions of the modules could be put on disk, and
> > depmod could be updated to point to them before starting the patching.
> > But that probably creates more headaches.
>
> Yeah. In theory, it probably works. I don't want to really see any attempt
> to have this implemented in practice though :)
Agreed...
--
Josh
--
To unsubscribe from this list: send the line "unsubscribe live-patching" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
