linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miroslav Benes <mbenes@suse.cz>
To: Joe Lawrence <joe.lawrence@redhat.com>
Cc: linux-kernel@vger.kernel.org, live-patching@vger.kernel.org,
	linux-kbuild@vger.kernel.org, Jessica Yu <jeyu@kernel.org>,
	Jiri Kosina <jikos@kernel.org>, Joao Moreira <jmoreira@suse.de>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Michael Matz <matz@suse.de>, Nicolai Stange <nstange@suse.de>,
	Petr Mladek <pmladek@suse.com>
Subject: Re: [PATCH v3 0/9] klp-convert livepatch build tooling
Date: Wed, 24 Apr 2019 20:19:07 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LSU.2.21.1904242013310.30239@pobox.suse.cz> (raw)
In-Reply-To: <20190417201316.GA690@redhat.com>

[...]

> Result: a small tweak to sympos_sanity_check() to relax its symbol
> uniqueness verification:  allow for duplicate <object, name, position>
> instances.  Now it will only complain when a supplied symbol references
> the same <object, name> but a different <position>.
> 
> diff --git a/scripts/livepatch/klp-convert.c b/scripts/livepatch/klp-convert.c
> index 82c27d219372..713835dfc9ec 100644
> --- a/scripts/livepatch/klp-convert.c
> +++ b/scripts/livepatch/klp-convert.c
> @@ -194,7 +194,10 @@ static void clear_sympos_annontations(struct elf *klp_elf)
>  	}
>  }
> 
> -/* Checks if two or more elements in usr_symbols have the same name */
> +/*
> + * Checks if two or more elements in usr_symbols have the same
> + * object and name, but different symbol position
> + */
>  static bool sympos_sanity_check(void)
>  {
>  	bool sane = true;
> @@ -203,7 +206,9 @@ static bool sympos_sanity_check(void)
>  	list_for_each_entry(sp, &usr_symbols, list) {
>  		aux = list_next_entry(sp, list);
>  		list_for_each_entry_from(aux, &usr_symbols, list) {
> -			if (strcmp(sp->symbol_name, aux->symbol_name) == 0) {
> +			if (sp->pos != aux->pos &&
> +			    strcmp(sp->object_name, aux->object_name) == 0 &&
> +			    strcmp(sp->symbol_name, aux->symbol_name) == 0)
>  				WARN("Conflicting KLP_SYMPOS definition: %s.%s,%d vs. %s.%s,%d.",
>  				sp->object_name, sp->symbol_name, sp->pos,
>  				aux->object_name, aux->symbol_name, aux->pos);

Looks good and I'd definitely include it in v4.

> Unique sympos
> -------------
> 
> But even with the above workaround, specifying unique symbol positions
> will (and should) result in a klp-convert complaint.
> 
> When modifying the test module with unique symbol position annotation
> values (1 and 2 respectively):
> 
>   test_klp_convert_multi_objs_a.c:
> 
>     extern void *state_show;
>     ...
>     KLP_MODULE_RELOC(vmlinux) vmlinux_relocs_b[] = {
>             KLP_SYMPOS(state_show, 1)
>     };
> 
>   test_klp_convert_multi_objs_b.c:
> 
>     extern void *state_show;
>     ...
>     KLP_MODULE_RELOC(vmlinux) vmlinux_relocs_b[] = {
>             KLP_SYMPOS(state_show, 2)
>     };
> 
> 
> Each object file's symbol table contains a "state_show" instance:
> 
>   % eu-readelf --symbols lib/livepatch/test_klp_convert_multi_objs_a.o | grep '\<state_show\>'
>      30: 0000000000000000      0 NOTYPE  GLOBAL DEFAULT    UNDEF state_show
> 
>   % eu-readelf --symbols lib/livepatch/test_klp_convert_multi_objs_b.o | grep '\<state_show\>'
>      20: 0000000000000000      0 NOTYPE  GLOBAL DEFAULT    UNDEF state_show
> 
> and the intermediate test_klp_convert_multi_objs.klp.o file contains a
> combined .klp.module_relocs.vmlinux relocation section with two
> KLP_SYMPOS structures, each with a unique <sympos> value:
> 
>   % objcopy -O binary --only-section=.klp.module_relocs.vmlinux \
>       lib/livepatch/test_klp_convert_multi_objs.klp.o >(hexdump)
> 
>   0000000 0000 0000 0000 0000 0001 0000 0000 0000
>   0000010 0000 0000 0002 0000
> 
> but the symbol tables were merged, sorted and non-unique symbols
> removed, leaving a *single* unresolved "state_show" instance:
> 
>   % eu-readelf --symbols lib/livepatch/test_klp_convert_multi_objs.klp.o | grep '\<state_show\>'
>      53: 0000000000000000      0 NOTYPE  GLOBAL DEFAULT    UNDEF state_show
> 
> which means that even though we have separate relocations for each
> "state_show" instance:
> 
>   Relocation section [ 6] '.rela.text.unlikely' for section [ 5] '.text.unlikely' at offset 0x44510 contains 11 entries:
>     Offset              Type            Value               Addend Name
>     0x0000000000000003  X86_64_32S      000000000000000000      +0 state_show
>     ...
>     0x0000000000000034  X86_64_32S      000000000000000000      +0 state_show
>     ...
> 
> they share the same rela->sym and there is no way to distinguish which
> one correlates to which KLP_SYMPOS structure.
> 
> 
> Future Work
> -----------
>
> I don't see an easy way to support multiple homonym <object, name>
> symbols with unique <position> values in the current livepatch module
> Elf format.  The only solutions that come to mind right now include
> renaming homonym symbols somehow to retain the relocation->symbol
> relationship when separate object files are combined.  Perhaps an
> intermediate linker step could make annotated symbols unique in some way
> to achieve this.  /thinking out loud

I'd set this aside for now and we can return to it later. I think it could 
be quite rare in practice.

I was thinking about renaming the symbol too. We can extend the symbol 
naming convention we have now and deal with it in klp_resolve_symbols(), 
but maybe Josh will come up with something clever and cleaner.
 
Miroslav

  reply	other threads:[~2019-04-24 18:19 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-10 15:50 [PATCH v3 0/9] klp-convert livepatch build tooling Joe Lawrence
2019-04-10 15:50 ` [PATCH v3 1/9] livepatch: Create and include UAPI headers Joe Lawrence
2019-04-11  0:32   ` Masahiro Yamada
2019-04-11 14:30     ` Joe Lawrence
2019-04-11 15:48       ` Josh Poimboeuf
2019-04-11 18:41       ` Miroslav Benes
2019-04-10 15:50 ` [PATCH v3 2/9] kbuild: Support for Symbols.list creation Joe Lawrence
2019-04-11  9:18   ` Artem Savkov
2019-04-11 15:18     ` Joe Lawrence
2019-04-11 19:04   ` Miroslav Benes
2019-04-16 14:13     ` Joe Lawrence
2019-04-16 19:02       ` Miroslav Benes
2019-04-10 15:50 ` [PATCH v3 3/9] livepatch: Add klp-convert tool Joe Lawrence
2019-04-10 18:22   ` Joe Lawrence
2019-04-12  9:02     ` Miroslav Benes
2019-04-23 20:35   ` Joe Lawrence
2019-04-24 17:47     ` Miroslav Benes
2019-04-24 21:00       ` Joe Lawrence
2019-04-10 15:50 ` [PATCH v3 4/9] livepatch: Add klp-convert annotation helpers Joe Lawrence
2019-04-10 18:18   ` Joe Lawrence
2019-04-12  9:14     ` Miroslav Benes
2019-04-10 15:50 ` [PATCH v3 5/9] modpost: Integrate klp-convert Joe Lawrence
2019-04-11 15:54   ` Joe Lawrence
2019-04-10 15:50 ` [PATCH v3 6/9] modpost: Add modinfo flag to livepatch modules Joe Lawrence
2019-04-12 10:43   ` Miroslav Benes
2019-04-10 15:50 ` [PATCH v3 7/9] livepatch: Add sample livepatch module Joe Lawrence
2019-04-10 15:50 ` [PATCH v3 8/9] documentation: Update on livepatch elf format Joe Lawrence
2019-04-10 15:50 ` [PATCH v3 9/9] livepatch/selftests: add klp-convert Joe Lawrence
2019-04-12 21:26 ` [PATCH v3 0/9] klp-convert livepatch build tooling Joe Lawrence
2019-04-16 11:37   ` Miroslav Benes
2019-05-03 14:29     ` Joe Lawrence
2019-05-06 14:39       ` Miroslav Benes
2019-04-16  5:24 ` Balbir Singh
2019-04-16  8:29   ` Miroslav Benes
2019-04-16 13:37   ` Joe Lawrence
2019-04-16 13:55 ` Joe Lawrence
2019-04-16 19:09   ` Miroslav Benes
2019-04-17 20:13 ` Joe Lawrence
2019-04-24 18:19   ` Miroslav Benes [this message]
2019-04-24 19:13     ` Joao Moreira
2019-04-24 19:23       ` Josh Poimboeuf
2019-04-24 19:31       ` Joe Lawrence

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LSU.2.21.1904242013310.30239@pobox.suse.cz \
    --to=mbenes@suse.cz \
    --cc=jeyu@kernel.org \
    --cc=jikos@kernel.org \
    --cc=jmoreira@suse.de \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@redhat.com \
    --cc=khlebnikov@yandex-team.ru \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=matz@suse.de \
    --cc=nstange@suse.de \
    --cc=pmladek@suse.com \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).