Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp609212pxb; Thu, 14 Jan 2021 14:03:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJxlsIqBPbmg/vmPad9aAD3OTwQ/NdaZr5+d3qRKRNEE0YKYdtjSW3gNGp1ZWUeQpycM+xGW X-Received: by 2002:a05:6402:c4:: with SMTP id i4mr7154339edu.152.1610661793383; Thu, 14 Jan 2021 14:03:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610661793; cv=none; d=google.com; s=arc-20160816; b=qvNoCbVRTsoRvlz2i4dztMvcGxvAiB0aqLNlpTrA1+3fCpRjsNvdiaN9FzHJvqS1Kq ZBilmFLebFk4079WxkFIxws+/sJYtoKtG71naGS9UgMzycL8umtGcQvyZjRnaxlRpQCh Yr4N0MkEfuHrqs+8HGH3BOj4cZ2jcGxcraSXzZpVFU15FCbrtDzHQvawbPRbUZ9Bc+PP CE6o5G5bk955oKrqC1+/LXdq77uIPpr0/p1YEtclLSly9Va89T5RsSe8/spcSIKRjDRd 9I7R2IWHhNepo6w5H3n3eFYIgfgtsWOaqNzMTYLhL+UuJszr4zrK/f1HJr3TCqCjnjb3 q0cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=cVv6S5EAOTDagu+nMi70jtjXxb9kx3oijm5M+lP6Ygs=; b=sq+mG/co5uBcJeBx0njUpQC6UoLrflh0SqTRU00bFXCHUxkcBaFg8NxkTVrksS55A2 nYkiOUeBGp0esuD96ZLkqc4pbX/fMyOVbTp8ZKSjSXaQZPpbPJ++UuCmVel70zv/dPmr k1yyUNKQSDREllbh/MoqBkZ4xq2X4VUNACcHS5G23xP/R0B0ikq5HGwxDkT429p7wKRX 53NABwDJnmR2J/vSxEbzQGw2SjRi760gtdWsI7LGtH0hw5i395jV2GWPUV9WZjf1gRUf CRDd4Rp+cMnLGCaUpI75HI+2jxrc6ep/NIpKSHeGwl6xNueXeXvqQ0FTqVNfwY5DsYMj Pe9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Y8Aex8dp; 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 i9si3115613edq.66.2021.01.14.14.02.48; Thu, 14 Jan 2021 14:03:13 -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=Y8Aex8dp; 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 S1727105AbhANWBx (ORCPT + 99 others); Thu, 14 Jan 2021 17:01:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49812 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726694AbhANWBx (ORCPT ); Thu, 14 Jan 2021 17:01:53 -0500 Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DFFF9C061575 for ; Thu, 14 Jan 2021 14:01:12 -0800 (PST) Received: by mail-pj1-x1032.google.com with SMTP id ce17so1727363pjb.5 for ; Thu, 14 Jan 2021 14:01:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cVv6S5EAOTDagu+nMi70jtjXxb9kx3oijm5M+lP6Ygs=; b=Y8Aex8dpCPbwIN1oi9AJv6gyfjMobB8p9rVK5PfKWQiaS3lJfKUMAGG9wxhLHcyhlP ViUAFbzg93PhfghW8ML1ZY1bEoWz1Q6kIDFf74gryB7hd88cfSqs+QQRAuYDEf5aE6r/ MYcGlGPKOT2GlcbSQYfCC1azlGGMoF3XVCwtby0k07noSpLONPEMsk9R9El8J+pamakd KYgbW7SQ1C7umr32+yCMbk+6+Xs5y056/CSi8qLkJKPTfr9KVaqb9CDJbhk7AyRbivmc gfG5DiVY5pUDpK7vrs5jDoQIURR0Vou1jMZaK7i21WKAeFoYyUZKapHVvoayM1RGdIN0 O5jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cVv6S5EAOTDagu+nMi70jtjXxb9kx3oijm5M+lP6Ygs=; b=lZ+deNlrGym/JCuHy5ZHvGt45QMfhkexVPo606BNw6+aGUGZC2zhvhgO5Zh6DyutYG RcLLiTVCW74nXhe50VVyTf3WK7jK/neNTalh0gpUqmVVFhm0HJFp1b0WlORHI/q09bbK isqqGZ+LEaj1fvE/f/qSavlISQzYR5bToQAGdMDwWWDWGj3mhHN+1XcEvH6OLa6n0WG8 I5HaMIXKr+P8YC4YS3tt3B5zVmteZPQq6VFS0rpfJg0dcw8QoOAka8mS8iwOgbfjzvt3 wdh3Qdv3q9O1hTsBfdwyXf6LoJKFfOQIAFrgTvgeu/BYfCaWgo/tmP/AgRP2TgmLowLM XD+w== X-Gm-Message-State: AOAM531MJe3erJGr/WKi2dCB7mnEml/dEk3oT0rPXDhIxIn/GPWKHWHY WmcmAAXAJmdSIxTUa6OO5+5gjUKGJc6af6DYwBwcRw== X-Received: by 2002:a17:90a:6ba4:: with SMTP id w33mr7202654pjj.32.1610661672195; Thu, 14 Jan 2021 14:01:12 -0800 (PST) MIME-Version: 1.0 References: <20210114211840.GA5617@linux-8ccs> <20210114215416.993167-1-maskray@google.com> In-Reply-To: <20210114215416.993167-1-maskray@google.com> From: Nick Desaulniers Date: Thu, 14 Jan 2021 14:01:01 -0800 Message-ID: Subject: Re: [PATCH v2] module: Ignore _GLOBAL_OFFSET_TABLE_ when warning for undefined symbols To: Fangrui Song , Jessica Yu Cc: LKML , clang-built-linux , Sam Ravnborg , Marco Elver Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 14, 2021 at 1:54 PM 'Fangrui Song' via Clang Built Linux wrote: > > 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 Thanks for the patch. Reviewed-by: Nick Desaulniers Jessica, would you mind adding when applying: Cc: as I suspect we might want this fixed in stable tree's branches, too. It might of interest to add: Link: https://sourceware.org/bugzilla/show_bug.cgi?id=27178 too. > --- > 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; > -- -- Thanks, ~Nick Desaulniers