Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp605973pxb; Thu, 14 Jan 2021 13:57:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJyKOh/pk6KWFBjoTG3hkr7axDmMEc3CTcxbaCYzSno6dLQvloOgaH3QHBKkYYZFbW4MJ6e1 X-Received: by 2002:a17:906:e15:: with SMTP id l21mr6773607eji.509.1610661473322; Thu, 14 Jan 2021 13:57:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610661473; cv=none; d=google.com; s=arc-20160816; b=oA1fGv/EZG2QUgsu8hJJ377cyGa3e8lSxFpyqGr+53z7XF1RoTbH2yni48eOD5NGTT s9buuHUE++Rkt2ZzsQpgLgUyTouRwjWQqcbU9e40M0vD4hH6iSr3Fsef9ytR0oE95ppP xQO3LaayFBb9wgFhy02QrSmxyVsC6oF5N2Exu9ABWMedSdUZphYoxbRgyFzBrs8F6Riy S+Sxfpn2a0j1cFWYHu6WZtjfohd9Ptd4EAKbdwktYoxOMKPNIgah9XTNAS1Y3/oA88Tn KwMyeNfwjrfFqv+yee8T3DGHMHdYQpkQbYKHs2J8iFxnLPtOC6IJd/SnYR1b9FV9UAiT eAow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:references:mime-version :message-id:in-reply-to:date:sender:dkim-signature; bh=tgOM7SvsAS/8SvjP8wI77AkB8qnFEk/NyLJDnsaz2Ek=; b=AyueoFx4NVy/yxSv0NZxq0GPBYKc1aSNHxVPgBMm5oxknPTBaOsMVFnMt9Mfz5/3zq GDvWUuORX8UmPgVQXFQzHrKHSbqX+3BNa3ZTHOMAN7Q1c4pbf6uGhmAahene33C6GN5O +d7eBJzMzU0MxsaFOQMLg6A3611Qim6DpUowK6yk6RbfZiy4CWzXQH9o8EbxHrpSWAUe 9Q/OWCo7ToYtCnkhy1G5xFox3RiY+eHvQrwz9Ybb4ecs//GRo4dWDOPYOtcdwn+O9w0v 3bkwVBTBR20hSrUPhE40taBGopEutyVG0718btGNIZiek6doGgLplz9T6V45euAOdRCL Be4A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="Nw9ejyj/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o11si3023535ejg.118.2021.01.14.13.57.30; Thu, 14 Jan 2021 13:57:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="Nw9ejyj/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730492AbhANVzB (ORCPT + 99 others); Thu, 14 Jan 2021 16:55:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48322 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726755AbhANVzB (ORCPT ); Thu, 14 Jan 2021 16:55:01 -0500 Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A6B85C061575 for ; Thu, 14 Jan 2021 13:54:20 -0800 (PST) Received: by mail-yb1-xb4a.google.com with SMTP id e74so3212348ybh.19 for ; Thu, 14 Jan 2021 13:54:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=sender:date:in-reply-to:message-id:mime-version:references:subject :from:to:cc; bh=tgOM7SvsAS/8SvjP8wI77AkB8qnFEk/NyLJDnsaz2Ek=; b=Nw9ejyj/jm8iXEDGJc7y1QJW0WDCrpoip0qLvOo5Z0mWJnQ8Zd7DabKvObaBaf0zHl iwzri++M0/R6H9af7MLTrA7MO2XfhrRpwo8fQhK1Wor2JZZuPHO4z8Ij7iq3rwghTiOa TSk4mAJWS9NBCckF3ceaEI2wUOuzQlNdUwHGB8nSx6AjRNePeTNIcjUlrMkizRlc5JRq Ik62om6Asn5t2lj4zHr492s4VzvmjR+LFRqcUoCsxQCDzBq5InMZxNm7S0ANeSvhnZyG hiiahpPTk27cSe6j6yjsxylzJXdwVPpJyNVnzhjNTGreWSla7sbSp6zPNTan7vx25Rcz 3X9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=tgOM7SvsAS/8SvjP8wI77AkB8qnFEk/NyLJDnsaz2Ek=; b=A1xC+HNdPFhjYSDIAJqiVownX0zpCpwCIdITIVRVky9nnFrxf47h4/+K6kFdtwYlwG Y/IaVLWd5rPSE3G0r4A1Ey7UT/iW6NbyX2TtRNjuU06crUH1QOoGBYdTwLCU4CksMGnz eQ/51I9bAOMuzQhQBRoV9IiZ1OLwEhVSrLtIZFrbmzRNUgdK2Yt97Rn4pl+v3DP8281h hlx4U9WFXKtq7FWCDssDjkKKSFKlaySqlukWS8POLo0cIfMBl3yIEQ3PUJyxg/7mvM9R SLZPtkVRSTAZHikqksNjgR8rXlTlKmGWd3M1KdRWbC8PtEOz0WkOZ0LziSc5jI1TF9MZ cpUQ== X-Gm-Message-State: AOAM533YZfSZS5ovEm8KKUMepbL1ZTiXwIO7FTNwOXu+W/45ZpbT6OqR tP/wLrPJhWDWXOfkPUKn8d/xLSSbF08/NovHe7uSQEr3q5KuxMDiB1HiAMIfcQVh/jHGYBPysGb DXcsEBO8yYDwh6AoN3O64b1GvH2qW2MlBAsICtiwjJYRdrOVJCLIcodxyLVCWC78JN9Lr52EH Sender: "maskray via sendgmr" X-Received: from maskray1.svl.corp.google.com ([2620:15c:2ce:0:a6ae:11ff:fe11:4abb]) (user=maskray job=sendgmr) by 2002:a25:500b:: with SMTP id e11mr13498852ybb.138.1610661259864; Thu, 14 Jan 2021 13:54:19 -0800 (PST) Date: Thu, 14 Jan 2021 13:54:16 -0800 In-Reply-To: <20210114211840.GA5617@linux-8ccs> Message-Id: <20210114215416.993167-1-maskray@google.com> Mime-Version: 1.0 References: <20210114211840.GA5617@linux-8ccs> X-Mailer: git-send-email 2.30.0.296.g2bfb1c46d8-goog Subject: [PATCH v2] module: Ignore _GLOBAL_OFFSET_TABLE_ when warning for undefined symbols From: Fangrui Song To: linux-kernel@vger.kernel.org, Jessica Yu Cc: clang-built-linux@googlegroups.com, Sam Ravnborg , Fangrui Song , Marco Elver Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org clang-12 -fno-pic (since https://github.com/llvm/llvm-project/commit/a084c0388e2a59b9556f2de0083333232da3f1d6) can emit `call __stack_chk_fail@PLT` instead of `call __stack_chk_fail` on x86. The two forms should have identical behaviors on x86-64 but the former causes GNU as<2.37 to produce an unreferenced undefined symbol _GLOBAL_OFFSET_TABLE_. (On x86-32, there is an R_386_PC32 vs R_386_PLT32 difference but the linker behavior is identical as far as Linux kernel is concerned.) Simply ignore _GLOBAL_OFFSET_TABLE_ for now, like what scripts/mod/modpost.c:ignore_undef_symbol does. This also fixes the problem for gcc/clang -fpie and -fpic, which may emit `call foo@PLT` for external function calls on x86. Note: ld -z defs and dynamic loaders do not error for unreferenced undefined symbols so the module loader is reading too much. If we ever need to ignore more symbols, the code should be refactored to ignore unreferenced symbols. Reported-by: Marco Elver Link: https://github.com/ClangBuiltLinux/linux/issues/1250 Signed-off-by: Fangrui Song --- kernel/module.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) --- Changes in v2: * Fix Marco's email address * Add a function ignore_undef_symbol similar to scripts/mod/modpost.c:ignore_undef_symbol diff --git a/kernel/module.c b/kernel/module.c index 4bf30e4b3eaa..278f5129bde2 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -2348,6 +2348,20 @@ static int verify_exported_symbols(struct module *mod) return 0; } +static int ignore_undef_symbol(Elf_Half emachine, const char *name) +{ + /* On x86, PIC code and Clang non-PIC code may have call foo@PLT. GNU as + * before 2.37 produces an unreferenced _GLOBAL_OFFSET_TABLE_ on x86-64. + * i386 has a similar problem but may not deserve a fix. + * + * If we ever have to ignore many symbols, consider refactoring the code to + * only warn if referenced by a relocation. + */ + if (emachine == EM_386 || emachine == EM_X86_64) + return !strcmp(name, "_GLOBAL_OFFSET_TABLE_"); + return 0; +} + /* Change all symbols so that st_value encodes the pointer directly. */ static int simplify_symbols(struct module *mod, const struct load_info *info) { @@ -2395,8 +2409,10 @@ static int simplify_symbols(struct module *mod, const struct load_info *info) break; } - /* Ok if weak. */ - if (!ksym && ELF_ST_BIND(sym[i].st_info) == STB_WEAK) + /* Ok if weak or ignored. */ + if (!ksym && + (ELF_ST_BIND(sym[i].st_info) == STB_WEAK || + ignore_undef_symbol(info->hdr->e_machine, name))) break; ret = PTR_ERR(ksym) ?: -ENOENT; -- 2.30.0.296.g2bfb1c46d8-goog