From: Chris J Arges <chris.j.arges@canonical.com>
To: live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
        jpoimboe@redhat.com, jikos@kernel.org, pmladek@suse.com,
        mbenes@suse.cz, jeyu@redhat.com
Cc: Chris J Arges <chris.j.arges@canonical.com>
Subject: [PATCH 0/3 v9] livepatch: disambiguate symbols with the same name
Date: Tue,  1 Dec 2015 20:40:53 -0600
Message-Id: <1449024076-16034-1-git-send-email-chris.j.arges@canonical.com>
In-Reply-To: <1448040325-32498-1-git-send-email-chris.j.arges@canonical.com>
References: <1448040325-32498-1-git-send-email-chris.j.arges@canonical.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3463
Lines: 78

Currently, patching objects with duplicate symbol names fail because the
creation of the sysfs function directory collides with the previous
attempt. Appending old_addr to the function name is problematic as it
reveals the address of the function being patch to a normal user. Using
the symbol's occurrence in kallsyms to postfix the function name in the
sysfs directory solves the issue of having consistent unique names and
ensuring that the address is not exposed to a normal user.

In addition, using the symbol position as the user's method to disambiguate
symbols instead of addr allows for disambiguating symbols in modules as
well for both function addresses and for relocs. This also simplifies much
of the code. Special handling for kASLR is no longer needed and can be
removed. The klp_find_verify_func_addr function can be replaced by
klp_find_object_symbol, and klp_verify_vmlinux_symbol and its callback can
be removed completely.

The following set of patches use symbol positioning instead of old
addresses to disambiguate symbols that have the same name in a given
object. This is necessary in order to be able to patch symbols with the
same name within the same object. This requires modifications to the
klp_func and klp_reloc structures to add an additional element. In addition
the scheme used for the func directory in sysfs is modified to append the
symbols occurrence in kallsyms.

In addition, I've tested this patchset against a modified kpatch. I
modified the kpatch livepatch scaffolding to set lreloc->sympos = 0, and
lfunc->old_sympos to the nth occurrence of the symbol for that object in
kallsyms. I was able to patch the same test patch as described here:
  https://github.com/dynup/kpatch/issues/493
I've also tested this with sample livepatch code to test if the various
old_sympos values work for unique and duplicate functions.

v9:
 - use mod->name instead of mod->obj->name for klp_find_object_symbol in
   klp_write_object_relocations
 - rebase on current master
 - tested with kpatch

v8:
 - explain motivation and necessity in initial patch
 - don't support sympos for external relocations

v7:
 - make count/pos checking in klp_find_callback more readable
 - fix klp_write_object_relocations sympos/external checking

v6:
 - move sympos arg before addr in klp_find_object_symbol
 - make comments more accurate, remove unnecessary whitespace
 - improve cover letter

v5:
 - remove val from klp_reloc struct
 - klp_write_object_relocations doesn't use sympos with external relocs
 - add Petr Mladek's patch to simplify relocated external symbol code
 - add optimization in klp_find_callback in unique case
 - remove klp_find_verify_func_addr
 - amend/remove commit messages/comments to be more precise


Chris J Arges (3):
  livepatch: add old_sympos as disambiguator field to klp_func
  livepatch: add sympos as disambiguator field to klp_reloc
  livepatch: function,sympos scheme in livepatch sysfs directory

 Documentation/ABI/testing/sysfs-kernel-livepatch |   6 +-
 include/linux/livepatch.h                        |  24 ++--
 kernel/livepatch/core.c                          | 164 ++++++++---------------
 3 files changed, 74 insertions(+), 120 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/