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.
[ ... 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.
> > 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 :)
Thanks,
--
Jiri Kosina
SUSE Labs
--
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
