Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp5570296pxv; Wed, 28 Jul 2021 14:02:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwe7O1Nys1Za1pSiiPZYGi5qkSdzY7lFiL0w0nJaXVIklg9CCdZCtcIzOqPha8vSCp9EW+e X-Received: by 2002:aa7:c489:: with SMTP id m9mr2109549edq.256.1627506122563; Wed, 28 Jul 2021 14:02:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627506122; cv=none; d=google.com; s=arc-20160816; b=MEu7JIo7+XYCZSfvCF75pBwVhPAA6T0UkoWjCYs6apmGGUpTAOvX9oi+i55lCJhXFf +dl4M3MiZhT12XbNHJTsNMYGVwZnPWK03Zy+ej0t5TnWjRh3yMAAJKEPC6G2nSOqzHVk tjZ7SZAnAWhcIN+HRF72DcKTYqsNZXf7vFowMpVASccMc+y6cmZ6hybtcAwczJ5QHPVk cw6KCg97Bl9kLtwIs1LWj60UMUZWyExkY9vJ8Q758kVKzQ8eQyR8WFTaUGT9B5yk5J5J l/Qu7rKwgifnbn4OBJnBh/nobVRAVTXE+IejcoFyBC5wuZ/OK2teqRfMeRYjcjXD00gJ y/TA== 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=pTsvjRA7QJHz6Ut4194ILaAL+6Y4KjG9H2G1vntGX6w=; b=i4rYLZNydvtfJ/Aynt6tN2RSL8uXDBDqJ3n843TCRzcbB2TlT/lXsU/N1ncQQ+TQiC x374YqQwa9HD49jdHMazIDQWt1V3ZyXNiQEd22yb4nufuNz36bnXCiwsp8aGNpClPT79 pWIKrqsHySDzo7CWQh7lJ4stxRO6MAfB6enKNf+ZABpsTTudTSvR/mXvA/wnzkE5Idkk mGbUuC7NOBgRXvpTA/E+CcijB4AzJraiI7YtAi5XgmcHXCLN13WQP4NXtsCP6B2QAAN3 xr/ioDtXhb7Ep+s9WK5wy2ya7RABZxcCkjRhDP5rsd8znnCowMklH2Eu3a6Z+DwL0z0G 20hQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=jYhXLyFx; 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 v6si793765ejg.102.2021.07.28.14.01.38; Wed, 28 Jul 2021 14:02:02 -0700 (PDT) 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=jYhXLyFx; 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 S231777AbhG1U5g (ORCPT + 99 others); Wed, 28 Jul 2021 16:57:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231666AbhG1U5g (ORCPT ); Wed, 28 Jul 2021 16:57:36 -0400 Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 49585C061757 for ; Wed, 28 Jul 2021 13:57:34 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id a201so6165865ybg.12 for ; Wed, 28 Jul 2021 13:57:34 -0700 (PDT) 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=pTsvjRA7QJHz6Ut4194ILaAL+6Y4KjG9H2G1vntGX6w=; b=jYhXLyFxy+0LDnmQx3ShWVphRBj1/9hh+jLt56xwmBb9htxCdFO1rIETWEMLIJQmSw PktIHjmim14n8bmqOPZAe8UC39MQnNukydEq2ToJ/NqXgPWJ1Eu7cQxIpCchjDI+4oAO pEybwP5Fj8bS3I73oGgy7aQm079ZD35eH1lteS4gHwXvl1y+VGEZ+U7iCNzjrBkNKtE9 sCNtxvla1OzOsktzEhyhkrSRHJ0fE2X6LZe65uBVMo7JuFT1sWxtuvvRUDgLTH7kbzEK 4ZbJkf2oU+CuLmuZOTv5QJd/8YpUxXVtYNcXOOjn/LFYPSus6Vj75Upwnky2oB1EG/1l +oyQ== 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=pTsvjRA7QJHz6Ut4194ILaAL+6Y4KjG9H2G1vntGX6w=; b=tRdDDybXt5duj9Zw6kNDlNbWHFBSUBRSrqrYNT7bCdDsBF6BO+zM+b0fr0YLBtlE5F lN6ey3iRa4Gv2XHY3aw0X9LKZOEB+r4llk7sxyRB8Ffanw1ZmHhcoAf12X9V/oBUt+nR ZPHFL43WbZqjraE3x9N+bvF2JL81n8sspE5V4F4cAYdjtZJiJWBNRJF8Ze88iI0Jy1DI T+EV6eBesL3yocUgzGSeln5/pL6nT/bJwbUBRrrx2IM3WZo71OF2ixbXjpZ/2qa6Iagv 1/tc2kV+eKohCemN8pgLBkINdpbqNQcfkpjYLUv8jLV/+RzxxF1tLqZxgH994F1iycaJ 3QGQ== X-Gm-Message-State: AOAM530BltYCWteHex2MXW1ib8SpiZiyrVkbJfUmdHWCrQ5QMOsHMM23 EI8OVNAPF0wWnO1Sm6fpwSF7++VxXlVuAPuIzaxW/g== X-Received: by 2002:a25:ba44:: with SMTP id z4mr2130612ybj.476.1627505853191; Wed, 28 Jul 2021 13:57:33 -0700 (PDT) MIME-Version: 1.0 References: <20210727131853.GA18032@pswork> <20210727140618.19130-1-treasure4paddy@gmail.com> In-Reply-To: <20210727140618.19130-1-treasure4paddy@gmail.com> From: Sami Tolvanen Date: Wed, 28 Jul 2021 13:57:21 -0700 Message-ID: Subject: Re: [PATCH v2] kallsyms: strip ThinLTO postfix ".cfi_jt" To: Padmanabha Srinivasaiah Cc: Jessica Yu , Kees Cook , Nathan Chancellor , Nick Desaulniers , Miroslav Benes , Petr Mladek , Miguel Ojeda , Joe Perches , Stephen Boyd , "Gustavo A. R. Silva" , LKML , clang-built-linux Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Tue, Jul 27, 2021 at 7:07 AM Padmanabha Srinivasaiah wrote: > > Clang ThinLTO adds a postfix ".cfi_jt" to a symbols of extern functions. These symbols are added with CONFIG_CFI_CLANG no matter which LTO mode is selected, so talking about ThinLTO here isn't quite correct. > For example this breaks syscall tracer that doesn't expect such postfix, > so strip out the postfix from the output. > > Signed-off-by: Padmanabha Srinivasaiah > --- > Change in v2: > - Use existing routine in kallsyms to strip postfix ".cfi_jt" from > extern function name. > - Modified the commit message accordingly > > kernel/kallsyms.c | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c > index 0ba87982d017..e9148626ae6c 100644 > --- a/kernel/kallsyms.c > +++ b/kernel/kallsyms.c > @@ -166,16 +166,20 @@ static unsigned long kallsyms_sym_address(int idx) > > #if defined(CONFIG_CFI_CLANG) && defined(CONFIG_LTO_CLANG_THIN) > /* > - * LLVM appends a hash to static function names when ThinLTO and CFI are > - * both enabled, i.e. foo() becomes foo$707af9a22804d33c81801f27dcfe489b. > - * This causes confusion and potentially breaks user space tools, so we > - * strip the suffix from expanded symbol names. > + * LLVM appends a hash to static function names and just ".cfi_jt" postfix > + * for non-static functions when both ThinLTO and CFI are enabled, Functions aren't technically speaking renamed to add a .cfi_jt postfix. Instead, these are separate symbols that point to the CFI jump table. Perhaps the comment should just say that we want to strip .cfi_jt from CFI jump table symbols? > + * i.e. for example foo() becomes foo$707af9a22804d33c81801f27dcfe489b. > + * This causes confusion and potentially breaks user space tools and > + * built-in components, so we strip the suffix from expanded symbol names. > */ > static inline bool cleanup_symbol_name(char *s) > { > char *res; > > res = strrchr(s, '$'); > + if (!res) > + res = strstr(s, ".cfi_jt"); > + > if (res) > *res = '\0'; This looks otherwise fine to me, but it's going to conflict with Nick's earlier patch: https://lore.kernel.org/lkml/20210707181814.365496-1-ndesaulniers@google.com/ Could you please rebase this on top of that, and take into account that we should do this when CONFIG_LTO_CLANG is enabled, not only with LTO_CLANG_THIN? Sami