lkml.org 
[lkml]   [2022]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v5] livepatch: Clear relocation targets on a module removal
On Wed, Aug 31, 2022 at 1:01 AM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
>
>
> Le 30/08/2022 à 20:53, Song Liu a écrit :
> > From: Miroslav Benes <mbenes@suse.cz>
> >
> > 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.
> >
> > On ppc64le, we have a similar issue:
> >
> > module_64: livepatch_nfsd: Expected nop after call, got e8410018 at e_show+0x60/0x548 [livepatch_nfsd]
> > livepatch: failed to initialize patch 'livepatch_nfsd' for module 'nfsd' (-8)
> > livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to load module 'nfsd'
> >
> > 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 <jpoimboe@redhat.com>
> > Signed-off-by: Miroslav Benes <mbenes@suse.cz>
> > Signed-off-by: Song Liu <song@kernel.org>
> >
> > ---
> >
> > NOTE: powerpc code has not be tested.
> >
> > Changes v4 = v5:
> > 1. Fix compile with powerpc.
>
> Not completely it seems.
>
> CC kernel/livepatch/core.o
> kernel/livepatch/core.c: In function 'klp_clear_object_relocations':
> kernel/livepatch/core.c:352:50: error: passing argument 1 of
> 'clear_relocate_add' from incompatible pointer type
> [-Werror=incompatible-pointer-types]
> 352 | clear_relocate_add(pmod->klp_info->sechdrs,
> | ~~~~~~~~~~~~~~^~~~~~~~~
> | |
> | Elf32_Shdr *
> {aka struct elf32_shdr *}
> In file included from kernel/livepatch/core.c:19:
> ./include/linux/moduleloader.h:76:37: note: expected 'Elf64_Shdr *' {aka
> 'struct elf64_shdr *'} but argument is of type 'Elf32_Shdr *' {aka
> 'struct elf32_shdr *'}
> 76 | void clear_relocate_add(Elf64_Shdr *sechdrs,
> | ~~~~~~~~~~~~^~~~~~~
> cc1: some warnings being treated as errors
>
>
> Fixup:
>
> diff --git a/include/linux/moduleloader.h b/include/linux/moduleloader.h
> index d22b36b84b4b..958e6da7f475 100644
> --- a/include/linux/moduleloader.h
> +++ b/include/linux/moduleloader.h
> @@ -73,7 +73,7 @@ int apply_relocate_add(Elf_Shdr *sechdrs,
> unsigned int relsec,
> struct module *mod);
> #ifdef CONFIG_LIVEPATCH
> -void clear_relocate_add(Elf64_Shdr *sechdrs,
> +void clear_relocate_add(Elf_Shdr *sechdrs,
> const char *strtab,
> unsigned int symindex,
> unsigned int relsec,
>
>
> But then the link fails.
>
> LD .tmp_vmlinux.kallsyms1
> powerpc64-linux-ld: kernel/livepatch/core.o: in function
> `klp_cleanup_module_patches_limited':
> core.c:(.text+0xdb4): undefined reference to `clear_relocate_add'

Hmm.. I am not seeing either error. Could you please share your .config file?

Thanks,
Song

\
 
 \ /
  Last update: 2022-08-31 19:06    [W:0.283 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site