From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E75FCC433EF for ; Fri, 11 Feb 2022 18:05:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352426AbiBKSFV (ORCPT ); Fri, 11 Feb 2022 13:05:21 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:51718 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231338AbiBKSFQ (ORCPT ); Fri, 11 Feb 2022 13:05:16 -0500 Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 800ACD4B for ; Fri, 11 Feb 2022 10:05:14 -0800 (PST) Received: by mail-yb1-xb30.google.com with SMTP id j12so5061416ybh.8 for ; Fri, 11 Feb 2022 10:05:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=bQCacAqu6AD3L5T1l4m/Dw/zcsi+Jlaw1qBbQHQJ5n8=; b=kLbjkhoYZDNiub72bMg9ZqtXNwhvLpNO+yW5ASu4uizUywougb5IgTN3A9j7vUzPCV ilbbSa1H6KXx7RaT+aD1shRHdR+F7jQhMY0UN+PZf0soTx4mDFCLBkN12LSn14MUXJMC bNY8Rs4cIcMre3iQE1bY1Ur1vW/u69KzewdCW2nJGe9IgAG6nvcuHwrTzvL46TewNu1r U+zUpHn0Hef8B9vTL4zTS59BQuQ6aJP1KPP4mXq58IjfIWdD1mYgt7ZNd5gv/gf0TIGs jwIuFW4tMTPcYA5dGPBW7M+tfiAM/VQkuwm1hqfpeOplL17TdnC+4+tTNbwqFwdIJkQ3 7MlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bQCacAqu6AD3L5T1l4m/Dw/zcsi+Jlaw1qBbQHQJ5n8=; b=Pc0dyvAYlKfhiPfU87s0nvDN2Vj4t/Rc5kdutjvvd6z6DnxgmwVpEkVQhmIwjPxTTh rOtT00WqTqKz7kss1i5sErYLT9rqNDUeu6f9nkX8KnPCBlP5k3DKWsK2sVYQJGrs4Oyq Ap9F4vNRTTFw0roKPHKzD5IKWOIJHqaXzsLDYD6p6yTgH7EXSsFlkySlgGW1IaCzYYp7 F0nm0mPQ1tVTRP4Vqod2oFoVhQyuWPj4wIPMsj4043PKHlyXi+FCGpgFJkAhqF5O4ZnR ykHElDWr8cAq9SqNp0JhvdrdpZRbCwmCGfLCEuxqGlF1Dnc3JLtuP8oFkKpHZCw9IVYg N00g== X-Gm-Message-State: AOAM532D0tyUXGCnntGjR0y0q7QQMFJV6endAF7/wLCNcjsfma35gLYD giErcmB038KKvKHWfh9jgQEVzWze7FOylOh7nP1cCQ== X-Google-Smtp-Source: ABdhPJwqwn2kG4R0P3X04f1gmCys5jwU2Zxegllqb4PCZmn/bHZrdEndwiA5mCsWiE6z6c7BUFdhF4f1GQkwwBkxWBE= X-Received: by 2002:a81:ce09:: with SMTP id t9mr2890290ywi.254.1644602713368; Fri, 11 Feb 2022 10:05:13 -0800 (PST) MIME-Version: 1.0 References: <20220209185752.1226407-1-alexandr.lobakin@intel.com> <20220209185752.1226407-3-alexandr.lobakin@intel.com> <20220211174130.xxgjoqr2vidotvyw@treble> In-Reply-To: <20220211174130.xxgjoqr2vidotvyw@treble> From: =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Date: Fri, 11 Feb 2022 10:05:02 -0800 Message-ID: Subject: Re: [PATCH v10 02/15] livepatch: avoid position-based search if `-z unique-symbol` is available To: Josh Poimboeuf Cc: Alexander Lobakin , linux-hardening@vger.kernel.org, x86@kernel.org, Borislav Petkov , Jesse Brandeburg , Kristen Carlson Accardi , Kees Cook , Miklos Szeredi , Ard Biesheuvel , Tony Luck , Bruce Schlobohm , Jessica Yu , kernel test robot , Miroslav Benes , Evgenii Shatokhin , Jonathan Corbet , Masahiro Yamada , Michal Marek , Nick Desaulniers , Herbert Xu , "David S. Miller" , Thomas Gleixner , Will Deacon , Ingo Molnar , Christoph Hellwig , Dave Hansen , "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Arnd Bergmann , Nathan Chancellor , Masami Hiramatsu , Marios Pomonis , Sami Tolvanen , "H.J. Lu" , Nicolas Pitre , linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-arch@vger.kernel.org, live-patching@vger.kernel.org, llvm@lists.linux.dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 11, 2022 at 9:41 AM Josh Poimboeuf wrote: > > On Wed, Feb 09, 2022 at 07:57:39PM +0100, Alexander Lobakin wrote: > > Position-based search, which means that if there are several symbols > > with the same name, the user needs to additionally provide the > > "index" of a desired symbol, is fragile. For example, it breaks > > when two symbols with the same name are located in different > > sections. > > > > Since a while, LD has a flag `-z unique-symbol` which appends > > numeric suffixes to the functions with the same name (in symtab > > and strtab). It can be used to effectively prevent from having > > any ambiguity when referring to a symbol by its name. > > In the patch description can you also give the version of binutils (and > possibly other linkers) which have the flag? GNU ld>=3D2.36 supports -z unique-symbol. ld.lld doesn't support -z unique-= symbol. I subscribe to llvm@lists.linux.dev and happen to notice this message (can't keep up with the changes...) I am a bit concerned with this option and replied last time on https://lore.kernel.org/r/20220105032456.hs3od326sdl4zjv4@google.com My full reasoning is on https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#z-unique-symb= ol > > Check for its availability and always prefer when the livepatching > > is on. It can be used unconditionally later on after broader testing > > on a wide variety of machines, but for now let's stick to the actual > > CONFIG_LIVEPATCH=3Dy case, which is true for most of distro configs > > anyways. > > Has anybody objected to just enabling it for *all* configs, not just for > livepatch? > > I'd much prefer that: the less "special" livepatch is (and the distros > which enable it), the better. And I think having unique symbols would > benefit some other components. > > > +++ b/kernel/livepatch/core.c > > @@ -143,11 +143,13 @@ static int klp_find_callback(void *data, const ch= ar *name, > > args->count++; > > > > /* > > - * Finish the search when the symbol is found for the desired pos= ition > > - * or the position is not defined for a non-unique symbol. > > + * Finish the search when unique symbol names are enabled > > + * or the symbol is found for the desired position or the > > + * position is not defined for a non-unique symbol. > > */ > > - if ((args->pos && (args->count =3D=3D args->pos)) || > > - (!args->pos && (args->count > 1))) > > + if (IS_ENABLED(CONFIG_LD_HAS_Z_UNIQUE_SYMBOL) || > > + (args->pos && args->count =3D=3D args->pos) || > > + (!args->pos && args->count > 1)) > > return 1; > > There's no real need to do this. The code already works as-is, even if > there are no unique symbols. > > Even if there are no duplicates, there's little harm in going through > all the symbols anyway, to check for errors just in case something > unexpected happened with the linking (unexpected duplicate) or the patch > creation (unexpected sympos). It's not a hot path, so performance isn't > really a concern. > > When the old linker versions eventually age out, we can then go strip > out all the sympos stuff. > > > @@ -169,6 +171,13 @@ static int klp_find_object_symbol(const char *objn= ame, const char *name, > > else > > kallsyms_on_each_symbol(klp_find_callback, &args); > > > > + /* > > + * If the LD's `-z unique-symbol` flag is available and enabled, > > + * sympos checks are not relevant. > > + */ > > + if (IS_ENABLED(CONFIG_LD_HAS_Z_UNIQUE_SYMBOL)) > > + sympos =3D 0; > > + > > Similarly, I don't see a need for this. If the patch is legit then > sympos should already be zero. If not, an error gets reported and the > patch fails to load. > > -- > Josh > > --=20 =E5=AE=8B=E6=96=B9=E7=9D=BF