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 35E26C433FE for ; Fri, 11 Feb 2022 18:35:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352746AbiBKSfm (ORCPT ); Fri, 11 Feb 2022 13:35:42 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:41680 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352741AbiBKSfl (ORCPT ); Fri, 11 Feb 2022 13:35:41 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0A51D184 for ; Fri, 11 Feb 2022 10:35:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1644604538; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=J8HfLfxVfcNiEkSEpweyJmi/8GyqJBZOj2yEwh6I5kQ=; b=XGGmP3QfVl44fLCqFFl1KefRu390e2u+YdYLP9JdFyhrQBTwfyrckJtyv5QCfEucemOvfc MUdA0qOJcBR3Aox7VuPuzeMWgQPdDR0IuKZFIQf+q7KdS82x9I9x4/9Jqj3F51fKvM5vYS TADmjhL+SE3iPMs2NmxGFfbtF/S7aTc= Received: from mail-oo1-f70.google.com (mail-oo1-f70.google.com [209.85.161.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-126-tGXgCzInMtiSwLtxBLc8Mw-1; Fri, 11 Feb 2022 13:35:35 -0500 X-MC-Unique: tGXgCzInMtiSwLtxBLc8Mw-1 Received: by mail-oo1-f70.google.com with SMTP id h7-20020a4aa287000000b002eb15de5797so6076791ool.23 for ; Fri, 11 Feb 2022 10:35:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=J8HfLfxVfcNiEkSEpweyJmi/8GyqJBZOj2yEwh6I5kQ=; b=p/4WCRL2b39ODD0NkPHQXPh7hNfnh47nJrai1I6Ysu3tkhvBTa3PSTkLy5JI0YkFF7 45FxClkHDYkUP6xcGfboF9qiZIucA+WI7hsnk4QF9N8P/96NOnD5IQQXq1uYL5R2NcNf GwCQVb8bH6b/hRuzO9xBhLMKzN36eTlcl0ZTbihgE6Juaiag7iJTilIXDYQf7BGt+40L QYEbXca+TYZ2yEZ+h/yqU5T/iwaEJEOOXsuqs41n0OTgHmA3N2of0PciJHZPuQ06LaA3 IXKavVBiUrQJa1v8WQXVe3PlslMYSpT4tbqsSIcrYarBSIHhd5bl9xWGwSxSpaNdRq/t jvag== X-Gm-Message-State: AOAM531LOLTb6xIvtf8Z4nVUXfHKctMBTwXStGtbeIWMSw+m6IAxl8f5 R7y04Izq5KmNtwQmSOnciW7IHqbCkGOkhVhHKRvy82vkq09kYf8gcuQ/cIpK5VYpdCLFJi+i0Vc 6L6uYx8BfZ1nLF5BHlmztB7YkAQLa X-Received: by 2002:a05:6830:19ed:: with SMTP id t13mr1078553ott.83.1644604535030; Fri, 11 Feb 2022 10:35:35 -0800 (PST) X-Google-Smtp-Source: ABdhPJwvxMA3qcq86xXsncmpwHUMHF94120N5jKw3TA/bT6HNPqEH7OwmhO+43BhJzSDitpUEbLUcg== X-Received: by 2002:a05:6830:19ed:: with SMTP id t13mr1078522ott.83.1644604534752; Fri, 11 Feb 2022 10:35:34 -0800 (PST) Received: from treble ([2600:1700:6e32:6c00::35]) by smtp.gmail.com with ESMTPSA id m7sm9451958ots.32.2022.02.11.10.35.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Feb 2022 10:35:34 -0800 (PST) Date: Fri, 11 Feb 2022 10:35:29 -0800 From: Josh Poimboeuf To: =?utf-8?B?RsSBbmctcnXDrCBTw7JuZw==?= 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 Subject: Re: [PATCH v10 02/15] livepatch: avoid position-based search if `-z unique-symbol` is available Message-ID: <20220211183529.q7qi2qmlyuscxyto@treble> References: <20220209185752.1226407-1-alexandr.lobakin@intel.com> <20220209185752.1226407-3-alexandr.lobakin@intel.com> <20220211174130.xxgjoqr2vidotvyw@treble> MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=jpoimboe@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-hardening@vger.kernel.org On Fri, Feb 11, 2022 at 10:05:02AM -0800, Fāng-ruì Sòng wrote: > 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>=2.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-symbol Ah, right. Also discussed here: https://lore.kernel.org/all/20210123225928.z5hkmaw6qjs2gu5g@google.com/T/#u https://lore.kernel.org/all/20210125172124.awabevkpvq4poqxf@treble/ I'm not qualified to comment on LTO/PGO stability issues, but it doesn't sound good. And we want to support livepatch for LTO kernels. Also I realized that this flag would have a negative effect on kpatch-build, as it currently does its analysis on .o files. So it would have to figure out how to properly detect function renames, to avoid patching the wrong function for example. And if LLD doesn't plan to support the flag then it will be a headache for livepatch (and the kernel in general) to deal with the divergent configs. One idea I mentioned before, it may be worth exploring changing the "F" in FGKASLR to "File" instead of "Function". In other words, only shuffle at an object-file granularity. Then, even with duplicates, the symbol pair doesn't change in the symbol table. And as a bonus, it should help FGKASLR i-cache performance, significantly. -- Josh