[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180604095416.rlthplerswzznyoc@d217.suse.de>
Date: Mon, 4 Jun 2018 11:54:16 +0200
From: Jessica Yu <jeyu@...nel.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: linux-kernel@...r.kernel.org, live-patching@...r.kernel.org
Subject: Re: /proc/kallsyms shows undefined symbols for livepatch modules
+++ Jessica Yu [04/06/18 10:05 +0200]:
>+++ Josh Poimboeuf [02/06/18 12:32 -0500]:
>>Hi Jessica,
>>
>>I found a bug:
>>
>> [root@f25 ~]# modprobe livepatch-sample
>> [root@f25 ~]# grep ' u ' /proc/kallsyms
>> ffffffff81161080 u klp_enable_patch [livepatch_sample]
>> ffffffff81a01800 u __fentry__ [livepatch_sample]
>> ffffffff81161250 u klp_unregister_patch [livepatch_sample]
>> ffffffff81161870 u klp_register_patch [livepatch_sample]
>> ffffffff8131f0b0 u seq_printf [livepatch_sample]
>>
>>Notice that livepatch modules' undefined symbols are showing up in
>>/proc/kallsyms. This can confuse klp_find_object_symbol() which can
>>cause subtle bugs in livepatch.
>>
>>I stared at the module kallsyms code for a bit, but I don't see the bug.
>>Maybe it has something to do with how we save the symbol table in
>>copy_module_elf(). Any ideas?
>
>Hi Josh!
>
>This is because we preserve the entire symbol table for livepatch
>modules, including the SHN_UNDEF symbols. IIRC, this is so that we can
>still apply relocations properly with apply_relocate_add() after a
>to-be-patched object is loaded. Normally we don't save these SHN_UNDEF
>symbols for modules so they do not appear in /proc/kallsyms.
Hm, if having the full symtab in kallsyms is causing trouble, one
possibility would be to just have the module kallsyms code simply
skip/ignore undef symbols. That's what we technically do for normal
modules anyway (we normally cut undef syms out of the symtab). Haven't
tested this idea but does that sound like it'd help?
Thanks,
Jessica
Powered by blists - more mailing lists