Re: [PATCH 0/1] Fix exported symbol klp-relocation bug

[Miroslav Benes <mbenes@suse.cz>]

Hi,

> Next: symbol namespaces
> =======================
> 
> Now a harder question, I think, about symbol namespaces.  In the past,
> kpatch-build had supported patching symbols in namespace where
> MODULE_IMPORT_NS() is allowed.  Looking at kvm :: mmu.c
> ::kvm_flush_remote_tlbs(), that is annotated with
> EXPORT_SYMBOL_FOR_KVM_INTERNAL() instead.
> 
> Should we make an effort to support klp-relocations / patching to this
> use-case?
> 
> If modpost were to let klp-relocation symbols through, I *think*
> (untested) that might be enough... but it seems like that may violate
> the spirit of what the namespacing effort is trying to achieve.
> 
> Note that klp-post-link converts these symbols to SHN_LIVEPATCH before
> the module is loaded, so the kernel module loader already skips them in
> simplify_symbols() (see SHN_LIVEPATCH case).  AFAICT, the namespace
> check in modpost is the only enforcement point, and it's checking a
> symbol that will never be resolved through the normal module loading
> path anyway.

I think we will see more and more EXPORT_SYMBOL_FOR_MODULES() in the 
kernel. kvm is probably by far the most interesting one for us as of now.

Tough. All changes in upstream so far, as I remember, around reducing the 
possibility to use internal symbols for OOT modules (like kallsyms API but 
there are probably more) have been done with KLP usage in mind. Or at 
least people tried. However, there is a limit to it. If we introduce a 
workaround in upstream for this, people will definitely use it to get 
around the enforcement in their OOT modules. We should avoid that in my 
opinion.

So I would keep whatever we come up with in downstream.

Reviewed-by: Miroslav Benes <mbenes@suse.cz> for the patch. Josh has 
already taken it so just for the record.

Miroslav