From patchwork Tue Aug 20 11:43:07 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Wieczorkiewicz, Pawel" X-Patchwork-Id: 11103659 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 7C9A213B1 for ; Tue, 20 Aug 2019 11:45:02 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4A9FD216F4 for ; Tue, 20 Aug 2019 11:45:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=amazon.de header.i=@amazon.de header.b="oEA2P0QA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4A9FD216F4 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=amazon.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1i02Xr-0002rW-86; Tue, 20 Aug 2019 11:43:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1i02Xp-0002qy-Om for xen-devel@lists.xen.org; Tue, 20 Aug 2019 11:43:21 +0000 X-Inumbo-ID: b5f4a346-c33f-11e9-b90c-bc764e2007e4 Received: from smtp-fw-2101.amazon.com (unknown [72.21.196.25]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b5f4a346-c33f-11e9-b90c-bc764e2007e4; Tue, 20 Aug 2019 11:43:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209; t=1566301401; x=1597837401; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version; bh=GHZTOYRG1SwCtEYp/gLLJOZxpDmLHyVNXu82ygiiyac=; b=oEA2P0QA4qIOfGSul9oF9x7kwi6ES2dzL+EKXaQyo67fLuvPvOnnmrVY HvNDfRe24wmYmJwK8s14tSDd2DzndrAIKcFiziB3RiL1/jscrslaG9Fu8 eUD8Dv+yEJ7uptCll9NHjvNnX1Io10XthHWevAoJFMmlpgz+kta934SX0 0=; X-IronPort-AV: E=Sophos;i="5.64,408,1559520000"; d="scan'208";a="747563638" Received: from iad6-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-1e-17c49630.us-east-1.amazon.com) ([10.124.125.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP; 20 Aug 2019 11:43:21 +0000 Received: from EX13MTAUEA001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-17c49630.us-east-1.amazon.com (Postfix) with ESMTPS id 432BAA2668; Tue, 20 Aug 2019 11:43:20 +0000 (UTC) Received: from EX13D03EUA001.ant.amazon.com (10.43.165.33) by EX13MTAUEA001.ant.amazon.com (10.43.61.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 20 Aug 2019 11:43:19 +0000 Received: from EX13MTAUEE001.ant.amazon.com (10.43.62.200) by EX13D03EUA001.ant.amazon.com (10.43.165.33) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 20 Aug 2019 11:43:18 +0000 Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33) by mail-relay.amazon.com (10.43.62.226) with Microsoft SMTP Server id 15.0.1367.3 via Frontend Transport; Tue, 20 Aug 2019 11:43:17 +0000 From: Pawel Wieczorkiewicz To: Date: Tue, 20 Aug 2019 11:43:07 +0000 Message-ID: <20190820114307.68018-1-wipawel@amazon.de> X-Mailer: git-send-email 2.16.5 In-Reply-To: <20190808124831.10094-1-wipawel@amazon.de> References: <20190808124831.10094-1-wipawel@amazon.de> MIME-Version: 1.0 Precedence: Bulk Subject: [Xen-devel] [livepatch-build-tools part3 v3 2/3] create-diff-object: Extend patchability verification: STN_UNDEF X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: mpohlack@amazon.de, ross.lagerwall@citrix.com, wipawel@amazon.de, konrad.wilk@oracle.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" During verification check if all sections do not contain any entries with undefined symbols (STN_UNDEF). This situation can happen when a section is copied over from its original object to a patched object, but various symbols related to the section are not copied along. This scenario happens typically during stacked hotpatches creation (between 2 different hotpatch modules). Signed-off-by: Pawel Wieczorkiewicz Reviewed-by: Martin Pohlack Reviewed-by: Bjoern Doebel Reviewed-by: Norbert Manthey Reviewed-by: Andra-Irina Paraschiv --- v3: * Fixed for() loop style * Changed comment according to Ross' recommendation. v2: * Refactored code by creating a new function kpatch_section_has_undef_symbols() for the complicated multi-loop code of kpatch_verify_patchability(). Hopefully this makes code more readable and easier to maintain. * Kept lines limits to 80 chars (whereever possible) * Detection of an undefined symbol counts as a single error --- create-diff-object.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) diff --git a/create-diff-object.c b/create-diff-object.c index 8edd93b..33cfa95 100644 --- a/create-diff-object.c +++ b/create-diff-object.c @@ -1530,6 +1530,61 @@ static void kpatch_print_changes(struct kpatch_elf *kelf) } } +static inline int get_section_entry_size(const struct section *sec, + struct kpatch_elf *kelf) +{ + int entry_size; + + /* + * Base sections typically do not define fixed size elements. + * Detect section's element size in case it's a special section. + * Otherwise, skip it due to an unknown sh_entsize. + */ + entry_size = sec->sh.sh_entsize; + if (entry_size == 0) { + struct special_section *special; + + /* Find special section group_size. */ + for (special = special_sections; special->name; special++) { + if (!strcmp(sec->name, special->name)) + return special->group_size(kelf, 0); + } + } + + return entry_size; +} + +static int kpatch_section_has_undef_symbols(struct kpatch_elf *kelf, + const struct section *sec) +{ + int offset, entry_size; + struct rela *rela; + size_t d_size; + + entry_size = get_section_entry_size(sec, kelf); + if (entry_size == 0) + return false; + + d_size = sec->base->data->d_size; + for (offset = 0; offset < d_size; offset += entry_size) { + list_for_each_entry(rela, &sec->relas, list) { + if (rela->offset < offset || + rela->offset >= offset + entry_size) { + continue; + } + + if ((GELF_R_SYM(rela->rela.r_info) == STN_UNDEF) || + (!rela->sym->include && rela->sym->status == SAME)) { + log_normal("section %s has an entry with an undefined symbol: %s\n", + sec->name, rela->sym->name ?: "none"); + return true; + } + } + } + + return false; +} + static void kpatch_verify_patchability(struct kpatch_elf *kelf) { struct section *sec; @@ -1562,6 +1617,17 @@ static void kpatch_verify_patchability(struct kpatch_elf *kelf) errs++; } } + + /* Check if a RELA section does not contain any entries with + * undefined symbols (STN_UNDEF). This situation can happen + * when a section is copied over from its original object to + * a patched object, but various symbols related to the section + * are not copied along. + */ + if (is_rela_section(sec)) { + if (kpatch_section_has_undef_symbols(kelf, sec)) + errs++; + } } /*