Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5127427yba; Wed, 10 Apr 2019 11:58:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqwBvexD37cjGsQ+oWYCmR8OrDASwWpEoo+FxBKaN+jePBalI20/BtGKJJhQ9mZzXmNV3iPY X-Received: by 2002:a17:902:a5ca:: with SMTP id t10mr44027098plq.234.1554922712340; Wed, 10 Apr 2019 11:58:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554922712; cv=none; d=google.com; s=arc-20160816; b=V3XzdGuV+D9NnnufY5p7Y0RPQiSF9LU/7RW3T8zTbN4BibleDm+YT/xVqD/Aw8z0Ur qlKW2wAfeDa6y6iMIyXJH+oDZXLqoNQf+iWRCgLd0lEwmvkMFDkOzCCp5hVCB5zmEBwr lpnDQzge89H2sbYkTzi02YejBNFz21CtslmPm7VMJk8dNZx53Qkkx2a/1p3QWk94ZHlc SeFBbaNgRHAU5V2eXgdqzOE7GvD6LhI80Ks2Oj5BIQQ15YnORFMmjo3kcg96RXh2iSE+ 25FL6oyBepLG4gvPHhFWPtD/JdS8wjLmJmxRqjegxp3hlaCRcbtI1zf+4HoLmkoXV5pR HdVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=f7VxNgP92nMPSPnTRl60IJH0HEKfJhY0mSI5itO02H0=; b=0csLTCRiMpKzRWBYpwh1AiC4HqwjUKx0c4eD5/Jx/elT5J6qU/akGMkKTfOry20EWl JKzZrg9MBkPpHcKX8XEhGbVEn7+zfeh6KuwfOr3JsuOjdJ1r23e/2k/WxIFxexvptWf9 wZkzvksc+bXaqL1/sEypuQBBJ/Nglgwp5CpBTJEyXt286NuMoCixdXuHTOIEsukFCIkn 9wvZQKa5U9V2ksj6wjGfhqZmVWhfINpEFpD1aCPGohHuAG1f/rdqlehFV3c+IWLOVP5d 4C1ClnJ45C0XwgPuBRpSoTTE74hiUqXrJoNBm6W8OFEK++l0+v2+utaWrSmjC3WDQgJD SOLg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j1si7220467pfc.194.2019.04.10.11.58.16; Wed, 10 Apr 2019 11:58:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387564AbfDJPvV (ORCPT + 99 others); Wed, 10 Apr 2019 11:51:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8874 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387507AbfDJPvR (ORCPT ); Wed, 10 Apr 2019 11:51:17 -0400 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 715083091740; Wed, 10 Apr 2019 15:51:16 +0000 (UTC) Received: from jlaw-desktop.bos.redhat.com (dhcp-17-208.bos.redhat.com [10.18.17.208]) by smtp.corp.redhat.com (Postfix) with ESMTP id 19A6A10694ED; Wed, 10 Apr 2019 15:51:15 +0000 (UTC) From: Joe Lawrence To: linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, linux-kbuild@vger.kernel.org Cc: Jessica Yu , Jiri Kosina , Joao Moreira , Joe Lawrence , Josh Poimboeuf , Konstantin Khlebnikov , Masahiro Yamada , Michael Matz , Miroslav Benes , Nicolai Stange , Petr Mladek Subject: [PATCH v3 8/9] documentation: Update on livepatch elf format Date: Wed, 10 Apr 2019 11:50:57 -0400 Message-Id: <20190410155058.9437-9-joe.lawrence@redhat.com> In-Reply-To: <20190410155058.9437-1-joe.lawrence@redhat.com> References: <20190410155058.9437-1-joe.lawrence@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Wed, 10 Apr 2019 15:51:16 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Joao Moreira Add a section to Documentation/livepatch/module-elf-format.txt describing how klp-convert works for fixing relocations. Signed-off-by: Joao Moreira Signed-off-by: Joe Lawrence --- Documentation/livepatch/livepatch.txt | 3 ++ Documentation/livepatch/module-elf-format.txt | 50 ++++++++++++++++--- 2 files changed, 47 insertions(+), 6 deletions(-) diff --git a/Documentation/livepatch/livepatch.txt b/Documentation/livepatch/livepatch.txt index 4627b41ff02e..873c11aee038 100644 --- a/Documentation/livepatch/livepatch.txt +++ b/Documentation/livepatch/livepatch.txt @@ -274,6 +274,9 @@ into three levels: absolute position in the database, but rather the order it has been found only for a particular object ( vmlinux or a kernel module ). Note that kallsyms allows for searching symbols according to the object name. + Uniquely named symbols may use a symbol position of 0. Non-unique + symbols need to specify their object / kallsyms position, starting + at position 1. + struct klp_object defines an array of patched functions (struct klp_func) in the same object. Where the object is either vmlinux diff --git a/Documentation/livepatch/module-elf-format.txt b/Documentation/livepatch/module-elf-format.txt index f21a5289a09c..7bef8432352a 100644 --- a/Documentation/livepatch/module-elf-format.txt +++ b/Documentation/livepatch/module-elf-format.txt @@ -2,7 +2,8 @@ Livepatch module Elf format =========================== -This document outlines the Elf format requirements that livepatch modules must follow. +This document outlines the Elf format requirements that livepatch modules must +follow. ----------------- Table of Contents @@ -25,8 +26,9 @@ Table of Contents 3.3.2 Required name format 3.3.3 Example livepatch symbol names 3.3.4 Example `readelf --symbols` output -4. Architecture-specific sections -5. Symbol table and Elf section access +4. Automatic conversion of unresolved relocations +5. Architecture-specific sections +6. Symbol table and Elf section access ---------------------------- 0. Background and motivation @@ -270,7 +272,8 @@ Livepatch symbol names must conform to the following format: [D] The position of the symbol in the object (as according to kallsyms) This is used to differentiate duplicate symbols within the same object. The symbol position is expressed numerically (0, 1, 2...). - The symbol position of a unique symbol is 0. + The symbol position of a unique symbol is 0. The symbol position of + the first non-unique symbol is 1, the second is 2, etc. 3.3.3 Example livepatch symbol names: ------------------------------------- @@ -293,8 +296,43 @@ Symbol table '.symtab' contains 127 entries: [*] Note that the 'Ndx' (Section index) for these symbols is SHN_LIVEPATCH (0xff20). "OS" means OS-specific. +-------------------------------------------------- +4. Automatic conversion of unresolved relocations +-------------------------------------------------- +Sometimes livepatches may operate on symbols which are not self-contained nor +exported. When this happens, these symbols remain unresolved in the elf object +and will trigger an error during the livepatch instantiation. + +Whenever possible, the kernel building infrastructure solves this problem +automatically. First, a symbol database containing information on all compiled +objects is built. Second, this database - a file named Symbols.list, placed in +the kernel source root directory - is used to identify targets for unresolved +relocations, converting them in the livepatch elf accordingly to the +specifications above-described. While the first stage is fully handled by the +building system, the second is done by a tool called klp-convert, which can be +found in "scripts/livepatch". + +When an unresolved relocation has as target a symbol whose name is also used by +different symbols throughout the kernel, the relocation cannot be resolved +automatically. In these cases, the livepatch developer must add annotations to +the livepatch, making it possible for the system to identify which is the +correct target amongst multiple homonymous symbols. Such annotations must be +done through a data structure as follows: + +struct KLP_MODULE_RELOC(object) data_structure_name[] = { + KLP_SYMPOS(symbol, pos) +}; + +In the above example, object refers to the object file which contains the +symbol, being vmlinux or a module; symbol refers to the symbol name that will +be relocated and pos is its position in the object. + +When a data structure like this is added to the livepatch, the resulting elf +will hold symbols that will be identified by klp-convert and used to solve name +ambiguities. + --------------------------------- -4. Architecture-specific sections +5. Architecture-specific sections --------------------------------- Architectures may override arch_klp_init_object_loaded() to perform additional arch-specific tasks when a target module loads, such as applying @@ -305,7 +343,7 @@ be easily identified when iterating through a patch module's Elf sections (See arch/x86/kernel/livepatch.c for a complete example). -------------------------------------- -5. Symbol table and Elf section access +6. Symbol table and Elf section access -------------------------------------- A livepatch module's symbol table is accessible through module->symtab. -- 2.20.1