Received: by 10.213.65.68 with SMTP id h4csp512515imn; Fri, 16 Mar 2018 10:01:42 -0700 (PDT) X-Google-Smtp-Source: AG47ELunzQUpMlHpoYaJiYXHwawbY54iaFFzU0qSjfFCz9MNjyD9WOpvR3wVtDhsUv9z9I5I3xCN X-Received: by 2002:a17:902:7d17:: with SMTP id z23-v6mr2938211pll.237.1521219702668; Fri, 16 Mar 2018 10:01:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521219702; cv=none; d=google.com; s=arc-20160816; b=wvsNcnedxYPp7HpaSkYDzOpPnDaByLxIBIzZdIjhiHq2YiLKxfW4iQ3fEl76jCDjE2 11TwD/WXZuEo8prRzMACthqIYIHbkjyci3i9mrd+dr6jdlBRaDFIZI1zjBemThBNgOCw 6hArXjHWwamjR6DZ5h0iVN5h6Uatl6LKL2odVHazZQvBe7w34zdoaYuvJQ3ls29Le336 52c+yhfBru3iprvO8mOwY6WfSCYlsOWVuMPwM/CZ+5BEvcgjtpWbGYQnRSpsga/cChaC Q000uy0xKsP1rgJmzqFx8d4FE+l96tJ0p+mzJiWm0nGurXyciigI4PqMHRn/7hbQ95UY 2bNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=1SJ30rZICdCmJivrPkX/ojY7bouFE/ijq3OQlBsWWbo=; b=tzK6cUdyhkPlnMvHIn5OjOKlr7+Wsz9sUEnMtJguUti8TK4rmkOKSM9Gok2xfozzDD vnZ8m7F1hW/aFuhIpJKSz7LfOKytqxmDObUMgtzejE4tkfPbQdw9eVsQNCMP7lzossio C0LQFi7yWYgk8zktNo0UPOO7WbKRoT96ErQ72u2ngQFE+IyaEMnxsaE3NX1Lm2mN7DiW LuxE6POeClgchgoOn1rvK0Ej8Rh/8yNaCUdSGWfnLytCI+SX7+4lN7vLeKFbsaxZVvkK bn05Ob5xXOltHuIkv8Qzfk0q9xrpFBbU3UEGyv8EEMTg+T7XS/AsgEne0DPwVJHWmM9v amGw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u19si5705814pfk.128.2018.03.16.10.01.27; Fri, 16 Mar 2018 10:01:42 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933649AbeCPPcz (ORCPT + 99 others); Fri, 16 Mar 2018 11:32:55 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:38158 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933619AbeCPPcv (ORCPT ); Fri, 16 Mar 2018 11:32:51 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 2A65F10EB; Fri, 16 Mar 2018 15:32:51 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "H.J. Lu" , Linus Torvalds , Matthias Kaehlcke Subject: [PATCH 4.9 70/86] x86: Treat R_X86_64_PLT32 as R_X86_64_PC32 Date: Fri, 16 Mar 2018 16:23:33 +0100 Message-Id: <20180316152322.088738569@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180316152317.167709497@linuxfoundation.org> References: <20180316152317.167709497@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: H.J. Lu commit b21ebf2fb4cde1618915a97cc773e287ff49173e upstream. On i386, there are 2 types of PLTs, PIC and non-PIC. PIE and shared objects must use PIC PLT. To use PIC PLT, you need to load _GLOBAL_OFFSET_TABLE_ into EBX first. There is no need for that on x86-64 since x86-64 uses PC-relative PLT. On x86-64, for 32-bit PC-relative branches, we can generate PLT32 relocation, instead of PC32 relocation, which can also be used as a marker for 32-bit PC-relative branches. Linker can always reduce PLT32 relocation to PC32 if function is defined locally. Local functions should use PC32 relocation. As far as Linux kernel is concerned, R_X86_64_PLT32 can be treated the same as R_X86_64_PC32 since Linux kernel doesn't use PLT. R_X86_64_PLT32 for 32-bit PC-relative branches has been enabled in binutils master branch which will become binutils 2.31. [ hjl is working on having better documentation on this all, but a few more notes from him: "PLT32 relocation is used as marker for PC-relative branches. Because of EBX, it looks odd to generate PLT32 relocation on i386 when EBX doesn't have GOT. As for symbol resolution, PLT32 and PC32 relocations are almost interchangeable. But when linker sees PLT32 relocation against a protected symbol, it can resolved locally at link-time since it is used on a branch instruction. Linker can't do that for PC32 relocation" but for the kernel use, the two are basically the same, and this commit gets things building and working with the current binutils master - Linus ] Signed-off-by: H.J. Lu Signed-off-by: Linus Torvalds Cc: Matthias Kaehlcke Signed-off-by: Greg Kroah-Hartman --- arch/x86/kernel/machine_kexec_64.c | 1 + arch/x86/kernel/module.c | 1 + arch/x86/tools/relocs.c | 3 +++ 3 files changed, 5 insertions(+) --- a/arch/x86/kernel/machine_kexec_64.c +++ b/arch/x86/kernel/machine_kexec_64.c @@ -524,6 +524,7 @@ int arch_kexec_apply_relocations_add(con goto overflow; break; case R_X86_64_PC32: + case R_X86_64_PLT32: value -= (u64)address; *(u32 *)location = value; break; --- a/arch/x86/kernel/module.c +++ b/arch/x86/kernel/module.c @@ -190,6 +190,7 @@ int apply_relocate_add(Elf64_Shdr *sechd goto overflow; break; case R_X86_64_PC32: + case R_X86_64_PLT32: if (*(u32 *)loc != 0) goto invalid_relocation; val -= (u64)loc; --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -769,9 +769,12 @@ static int do_reloc64(struct section *se break; case R_X86_64_PC32: + case R_X86_64_PLT32: /* * PC relative relocations don't need to be adjusted unless * referencing a percpu symbol. + * + * NB: R_X86_64_PLT32 can be treated as R_X86_64_PC32. */ if (is_percpu_sym(sym, symname)) add_reloc(&relocs32neg, offset);