On Tue, 14 Jul 2015, Josh Poimboeuf wrote: > On Tue, Jul 14, 2015 at 04:36:35PM +0200, Miroslav Benes wrote: [...] > > As you mention above this is bypassing of EXPORT_SYMBOL (and > > EXPORT_SYMBOL_GPL) logic. > > This isn't anything new. We're already bypassing EXPORT_SYMBOL today > with klp_write_module_reloc(). The proposal is to do it more sanely. But that is slightly different. Sure one could bypass EXPORT_SYMBOL with klp_write_module_reloc() even today, but he must pretend it is the livepatch module with the structure filled in correctly to some degree. That makes it an obstacle (not hard to overcome I admit). With the RFC we would make it easier. It would be sufficient to mark the module as livepatch in modinfo (taking the code Jessica sent as an example) and that is all. > > Even if we mark each relevant unresolved symbol > > as for klp-only use there would be no obstacle for anyone else to do it. > > If you come up with the solution that would bind this feature with klp > > only we could discuss it more. But I am not sure otherwise. > > Well, it's already possible for any module to bypass EXPORT_SYMBOL today > if they really want to, thanks to kallsyms_lookup_name(). True. > But yeah, we should at least keep some obstacles in place. This needs > more thought and discussion. Agreed. I think we don't want to introduce easy to use "backdoor" in klp. That would be unfortunate. > > So I still think it is not a good idea because of EXPORT_SYMBOL and > > because of delayed module loading. Do you have the implementation already > > (even if not complete) somewhere? What are exactly the problems with s390x > > relocation types (I still haven't looked into them :/)? > > Jessica can better answer this question, but it has to do with the fact > that s390 relies on PLT/GOT tables. Technically I don't think it's an > insurmountable obstacle. It might be fixable be changing the > klp_write_module_reloc() interface and adding more intelligence to > kpatch-build. Yes, Jessica explained the situation very well. More on that in my other mail. > But it's a little crazy to keep bending over backwards to add support > for architectures, when all the code we need for every arch is already > in the kernel module loader today. I see the benefits of the approach and agree with them. I still feel uncomfortable and my concerns have not vanished at the same time. What needs to happen now is to consult Rusty, I think. After his reaction we can discuss the next steps. Best regards, Miroslav -- 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
