user/sven/linux.git/kernel/livepatch/core.c, branch v6.3.3

Merge tag 'livepatching-for-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching

2023-02-23T22:00:10Z

Pull livepatching updates from Petr Mladek: - Allow reloading a livepatched module by clearing livepatch-specific relocations in the livepatch module. Otherwise, the repeated load would fail on consistency checks. * tag 'livepatching-for-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching: livepatch,x86: Clear relocation targets on a module removal x86/module: remove unused code in __apply_relocate_add

livepatch,x86: Clear relocation targets on a module removal

2023-02-03T10:28:22Z

Josh reported a bug: When the object to be patched is a module, and that module is rmmod'ed and reloaded, it fails to load with: module: x86/modules: Skipping invalid relocation target, existing value is nonzero for type 2, loc 00000000ba0302e9, val ffffffffa03e293c livepatch: failed to initialize patch 'livepatch_nfsd' for module 'nfsd' (-8) livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to load module 'nfsd' The livepatch module has a relocation which references a symbol in the _previous_ loading of nfsd. When apply_relocate_add() tries to replace the old relocation with a new one, it sees that the previous one is nonzero and it errors out. He also proposed three different solutions. We could remove the error check in apply_relocate_add() introduced by commit eda9cec4c9a1 ("x86/module: Detect and skip invalid relocations"). However the check is useful for detecting corrupted modules. We could also deny the patched modules to be removed. If it proved to be a major drawback for users, we could still implement a different approach. The solution would also complicate the existing code a lot. We thus decided to reverse the relocation patching (clear all relocation targets on x86_64). The solution is not universal and is too much arch-specific, but it may prove to be simpler in the end. Reported-by: Josh Poimboeuf Originally-by: Miroslav Benes Signed-off-by: Song Liu Acked-by: Miroslav Benes Reviewed-by: Petr Mladek Acked-by: Josh Poimboeuf Reviewed-by: Joe Lawrence Tested-by: Joe Lawrence Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20230125185401.279042-2-song@kernel.org

livepatch: Improve the search performance of module_kallsyms_on_each_symbol()

2023-01-20T01:07:15Z

Currently we traverse all symbols of all modules to find the specified function for the specified module. But in reality, we just need to find the given module and then traverse all the symbols in it. Let's add a new parameter 'const char *modname' to function module_kallsyms_on_each_symbol(), then we can compare the module names directly in this function and call hook 'fn' after matching. If 'modname' is NULL, the symbols of all modules are still traversed for compatibility with other usage cases. Phase1: mod1-->mod2..(subsequent modules do not need to be compared) | Phase2: -->f1-->f2-->f3 Assuming that there are m modules, each module has n symbols on average, then the time complexity is reduced from O(m * n) to O(m) + O(n). Reviewed-by: Petr Mladek Acked-by: Song Liu Signed-off-by: Zhen Lei Signed-off-by: Jiri Olsa Acked-by: Miroslav Benes Reviewed-by: Luis Chamberlain Link: https://lore.kernel.org/r/20230116101009.23694-2-jolsa@kernel.org Signed-off-by: Alexei Starovoitov

livepatch: Call klp_match_callback() in klp_find_callback() to avoid code duplication

2022-12-13T02:30:58Z

The implementation of function klp_match_callback() is identical to the partial implementation of function klp_find_callback(). So call function klp_match_callback() in function klp_find_callback() instead of the duplicated code. Signed-off-by: Zhen Lei Acked-by: Song Liu Reviewed-by: Petr Mladek Suggested-by: Petr Mladek Signed-off-by: Luis Chamberlain

livepatch: Use kallsyms_on_each_match_symbol() to improve performance

2022-11-13T02:47:36Z

Based on the test results of kallsyms_on_each_match_symbol() and kallsyms_on_each_symbol(), the average performance can be improved by more than 1500 times. Signed-off-by: Zhen Lei Signed-off-by: Luis Chamberlain

Merge tag 'livepatching-for-6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching

2022-10-10T18:36:19Z

Pull livepatching updates from Petr Mladek: - Fix race between fork and livepatch transition revert - Add sysfs entry that shows "patched" state for each object (module) that can be livepatched by the given livepatch - Some clean up * tag 'livepatching-for-6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching: selftests/livepatch: add sysfs test livepatch: add sysfs entry "patched" for each klp_object selftests/livepatch: normalize sysctl error message livepatch: Add a missing newline character in klp_module_coming() livepatch: fix race between fork and KLP transition

Merge branch 'for-6.1/sysfs-patched-object' into for-linus

2022-10-05T11:00:03Z

kallsyms: increase maximum kernel symbol length to 512

2022-09-28T06:56:25Z

Rust symbols can become quite long due to namespacing introduced by modules, types, traits, generics, etc. For instance, the following code: pub mod my_module { pub struct MyType; pub struct MyGenericType(T); pub trait MyTrait { fn my_method() -> u32; } impl MyTrait for MyGenericType { fn my_method() -> u32 { 42 } } } generates a symbol of length 96 when using the upcoming v0 mangling scheme: _RNvXNtCshGpAVYOtgW1_7example9my_moduleINtB2_13MyGenericTypeNtB2_6MyTypeENtB2_7MyTrait9my_method At the moment, Rust symbols may reach up to 300 in length. Setting 512 as the maximum seems like a reasonable choice to keep some headroom. Reviewed-by: Kees Cook Reviewed-by: Petr Mladek Reviewed-by: Greg Kroah-Hartman Co-developed-by: Alex Gaynor Signed-off-by: Alex Gaynor Co-developed-by: Wedson Almeida Filho Signed-off-by: Wedson Almeida Filho Co-developed-by: Gary Guo Signed-off-by: Gary Guo Co-developed-by: Boqun Feng Signed-off-by: Boqun Feng Signed-off-by: Miguel Ojeda

livepatch: add sysfs entry "patched" for each klp_object

2022-09-23T14:06:18Z

Add per klp_object sysfs entry "patched". It makes it easier to debug typos in the module name. Signed-off-by: Song Liu Reviewed-by: Joe Lawrence [pmladek@suse.com: Updated kernel version when the sysfs file will be introduced] Reviewed-by: Petr Mladek Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20220902205208.3117798-2-song@kernel.org

livepatch: Add a missing newline character in klp_module_coming()

2022-09-01T14:27:59Z

The error message is not printed immediately because it does not end with a newline character. Before: root@localhost:~# insmod vmlinux.ko insmod: ERROR: could not insert module vmlinux.ko: Invalid parameters After: root@localhost:~# insmod vmlinux.ko [ 43.982558] livepatch: vmlinux.ko: invalid module name insmod: ERROR: could not insert module vmlinux.ko: Invalid parameters Fixes: dcf550e52f56 ("livepatch: Disallow vmlinux.ko") Signed-off-by: Zhen Lei Reviewed-by: Petr Mladek Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20220830112855.749-1-thunder.leizhen@huawei.com