From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: [PATCH v5 13/36] vmlinux.lds.h: add PGO and AutoFDO input sections Date: Fri, 31 Jul 2020 23:18:02 -0700 Message-ID: <202007312237.4F385EB3@keescook> References: <20200731230820.1742553-1-keescook@chromium.org> <20200731230820.1742553-14-keescook@chromium.org> <20200801035128.GB2800311@rani.riverdale.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: <20200801035128.GB2800311@rani.riverdale.lan> Sender: stable-owner@vger.kernel.org To: Arvind Sankar Cc: Thomas Gleixner , Will Deacon , Nick Desaulniers , Jian Cai , =?utf-8?B?RsSBbmctcnXDrCBTw7JuZw==?= , Luis Lozano , Manoj Gupta , stable@vger.kernel.org, Catalin Marinas , Mark Rutland , Ard Biesheuvel , Peter Collingbourne , James Morse , Borislav Petkov , Ingo Molnar , Russell King , Masahiro Yamada , Nathan Chancellor , Arnd Bergmann , x86@kernel.org, clang-built-linux@googlegroups.com, linux- List-Id: linux-arch.vger.kernel.org On Fri, Jul 31, 2020 at 11:51:28PM -0400, Arvind Sankar wrote: > On Fri, Jul 31, 2020 at 04:07:57PM -0700, Kees Cook wrote: > > From: Nick Desaulniers > > > > Basically, consider .text.{hot|unlikely|unknown}.* part of .text, too. > > > > When compiling with profiling information (collected via PGO > > instrumentations or AutoFDO sampling), Clang will separate code into > > .text.hot, .text.unlikely, or .text.unknown sections based on profiling > > information. After D79600 (clang-11), these sections will have a > > trailing `.` suffix, ie. .text.hot., .text.unlikely., .text.unknown.. > > > > When using -ffunction-sections together with profiling infomation, > > either explicitly (FGKASLR) or implicitly (LTO), code may be placed in > > sections following the convention: > > .text.hot., .text.unlikely., .text.unknown. > > where , , and are functions. (This produces one section > > per function; we generally try to merge these all back via linker script > > so that we don't have 50k sections). > > > > For the above cases, we need to teach our linker scripts that such > > sections might exist and that we'd explicitly like them grouped > > together, otherwise we can wind up with code outside of the > > _stext/_etext boundaries that might not be mapped properly for some > > architectures, resulting in boot failures. > > > > If the linker script is not told about possible input sections, then > > where the section is placed as output is a heuristic-laiden mess that's > > non-portable between linkers (ie. BFD and LLD), and has resulted in many > > hard to debug bugs. Kees Cook is working on cleaning this up by adding > > --orphan-handling=warn linker flag used in ARCH=powerpc to additional > > architectures. In the case of linker scripts, borrowing from the Zen of > > Python: explicit is better than implicit. > > > > Also, ld.bfd's internal linker script considers .text.hot AND > > .text.hot.* to be part of .text, as well as .text.unlikely and > > .text.unlikely.*. I didn't see support for .text.unknown.*, and didn't > > see Clang producing such code in our kernel builds, but I see code in > > LLVM that can produce such section names if profiling information is > > missing. That may point to a larger issue with generating or collecting > > profiles, but I would much rather be safe and explicit than have to > > debug yet another issue related to orphan section placement. > > > > Reported-by: Jian Cai > > Suggested-by: Fāng-ruì Sòng > > Tested-by: Luis Lozano > > Tested-by: Manoj Gupta > > Acked-by: Kees Cook > > Cc: stable@vger.kernel.org > > Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=add44f8d5c5c05e08b11e033127a744d61c26aee > > Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=1de778ed23ce7492c523d5850c6c6dbb34152655 > > Link: https://reviews.llvm.org/D79600 > > Link: https://bugs.chromium.org/p/chromium/issues/detail?id=1084760 > > Debugged-by: Luis Lozano > > Signed-off-by: Nick Desaulniers > > Signed-off-by: Kees Cook > > --- > > include/asm-generic/vmlinux.lds.h | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h > > index 2593957f6e8b..af5211ca857c 100644 > > --- a/include/asm-generic/vmlinux.lds.h > > +++ b/include/asm-generic/vmlinux.lds.h > > @@ -561,7 +561,10 @@ > > */ > > #define TEXT_TEXT \ > > ALIGN_FUNCTION(); \ > > - *(.text.hot TEXT_MAIN .text.fixup .text.unlikely) \ > > + *(.text.hot .text.hot.*) \ > > + *(TEXT_MAIN .text.fixup) \ > > + *(.text.unlikely .text.unlikely.*) \ > > + *(.text.unknown .text.unknown.*) \ > > NOINSTR_TEXT \ > > *(.text..refcount) \ > > *(.ref.text) \ > > -- > > 2.25.1 > > > > This also changes the ordering to place all hot resp unlikely sections separate > from other text, while currently it places the hot/unlikely bits of each file > together with the rest of the code in that file. That seems like a reasonable Oh, hmm, yes, we aren't explicitly using SORT() here. Does that mean the input sections were entirely be ordered in compilation unit link order, even in the case of orphan sections? (And I think either way, the answer isn't the same between bfd and lld.) I actually thought the like-named input sections were collected together first with lld, but bfd strictly appended to the output section. I guess it's time for me to stare at -M output from ld... Regardless, this patch is attempting to fix the problem where bfd and lld lay out the orphans differently (as mentioned above, lld seems to sort them in a way that is not strictly appended, and bfd seems to sort them strictly appended). In the case of being appended to the .text output section, this would cause boot failures due to _etext not covering the resulting sections (which this[1] also encountered and fixed to be more robust for such appended collection -- that series actually _depends_ on orphan handling doing the appending, because there is no current way to map wildcard input sections to their own separate output sections). > change and should be mentioned in the commit message. > > However, the history of their being together comes from > > 9bebe9e5b0f3 ("kbuild: Fix .text.unlikely placement") > > which seems to indicate there was some problem with having them separated out, > although I don't quite understand what the issue was from the commit message. Looking at this again, I actually wonder if we have bigger issues here with dead code elimination: #ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION #define TEXT_MAIN .text .text.[0-9a-zA-Z_]* ... that would catch: .text.hot .text.fixup .text.unlikely and .text.unknown but not .text.hot.*, etc (i.e. the third dot isn't matched, which is, I assume, why Clang switched to adding a trailing dot). However, this patch lists .text.hot .text.hot.* first, so they'd get pulled to the front correctly, but the trailing ones (with 2 dots) would not, since they'd match the TEXT_MAIN wildcard first. (This problem actually existed before this patch too, and is not the fault of 9bebe9e5b0f3, but rather the addition of TEXT_MAIN, which could potentially match .text.unlikely and .text.fixup) Unless I'm totally wrong and the bfd docs don't match the behavior? e.g. if I have a link order of ".foo.before", ".foo.after", and ".foo.middle", and this rule: .foo : { *(.foo.before .foo.* .foo.after) } do I get this (first match): .foo.before .foo.after .foo.middle or (most specific match): .foo.before .foo.middle .foo.after ? As I said, now that I'm able to better articulate these questions, I'll go get answers from -M output. :) Perhaps we need to fix TEXT_MAIN not TEXT_TEXT? TEXT_TEXT is for collecting .text, .text.[^\.]* and *.text, where, effectively, .text and .text[^\.]* are defined by TEXT_MAIN. i.e. adding 3-dot "text" input sections needs to likely be included in TEXT_MAIN Anyway, I'll keep looking at this... (In the meantime, perhaps we can take Arvind's series, and the earlier portions of the orphan series where asm-generic/vmlinux.lds.h and other things are cleaned up...) -Kees [1] https://lore.kernel.org/lkml/20200717170008.5949-6-kristen@linux.intel.com/ -- Kees Cook From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54840 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725275AbgHAGSF (ORCPT ); Sat, 1 Aug 2020 02:18:05 -0400 Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EE7A9C06174A for ; Fri, 31 Jul 2020 23:18:04 -0700 (PDT) Received: by mail-pf1-x443.google.com with SMTP id u185so15525345pfu.1 for ; Fri, 31 Jul 2020 23:18:04 -0700 (PDT) Date: Fri, 31 Jul 2020 23:18:02 -0700 From: Kees Cook Subject: Re: [PATCH v5 13/36] vmlinux.lds.h: add PGO and AutoFDO input sections Message-ID: <202007312237.4F385EB3@keescook> References: <20200731230820.1742553-1-keescook@chromium.org> <20200731230820.1742553-14-keescook@chromium.org> <20200801035128.GB2800311@rani.riverdale.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200801035128.GB2800311@rani.riverdale.lan> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Arvind Sankar Cc: Thomas Gleixner , Will Deacon , Nick Desaulniers , Jian Cai , =?utf-8?B?RsSBbmctcnXDrCBTw7JuZw==?= , Luis Lozano , Manoj Gupta , stable@vger.kernel.org, Catalin Marinas , Mark Rutland , Ard Biesheuvel , Peter Collingbourne , James Morse , Borislav Petkov , Ingo Molnar , Russell King , Masahiro Yamada , Nathan Chancellor , Arnd Bergmann , x86@kernel.org, clang-built-linux@googlegroups.com, linux-arch@vger.kernel.org, linux-efi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Andi Kleen , Michal Marek , Kristen Carlson Accardi Message-ID: <20200801061802.fiRW0L5qu9n9Mdll44V29UNzEON2A82sG4qfzo4JdFU@z> On Fri, Jul 31, 2020 at 11:51:28PM -0400, Arvind Sankar wrote: > On Fri, Jul 31, 2020 at 04:07:57PM -0700, Kees Cook wrote: > > From: Nick Desaulniers > > > > Basically, consider .text.{hot|unlikely|unknown}.* part of .text, too. > > > > When compiling with profiling information (collected via PGO > > instrumentations or AutoFDO sampling), Clang will separate code into > > .text.hot, .text.unlikely, or .text.unknown sections based on profiling > > information. After D79600 (clang-11), these sections will have a > > trailing `.` suffix, ie. .text.hot., .text.unlikely., .text.unknown.. > > > > When using -ffunction-sections together with profiling infomation, > > either explicitly (FGKASLR) or implicitly (LTO), code may be placed in > > sections following the convention: > > .text.hot., .text.unlikely., .text.unknown. > > where , , and are functions. (This produces one section > > per function; we generally try to merge these all back via linker script > > so that we don't have 50k sections). > > > > For the above cases, we need to teach our linker scripts that such > > sections might exist and that we'd explicitly like them grouped > > together, otherwise we can wind up with code outside of the > > _stext/_etext boundaries that might not be mapped properly for some > > architectures, resulting in boot failures. > > > > If the linker script is not told about possible input sections, then > > where the section is placed as output is a heuristic-laiden mess that's > > non-portable between linkers (ie. BFD and LLD), and has resulted in many > > hard to debug bugs. Kees Cook is working on cleaning this up by adding > > --orphan-handling=warn linker flag used in ARCH=powerpc to additional > > architectures. In the case of linker scripts, borrowing from the Zen of > > Python: explicit is better than implicit. > > > > Also, ld.bfd's internal linker script considers .text.hot AND > > .text.hot.* to be part of .text, as well as .text.unlikely and > > .text.unlikely.*. I didn't see support for .text.unknown.*, and didn't > > see Clang producing such code in our kernel builds, but I see code in > > LLVM that can produce such section names if profiling information is > > missing. That may point to a larger issue with generating or collecting > > profiles, but I would much rather be safe and explicit than have to > > debug yet another issue related to orphan section placement. > > > > Reported-by: Jian Cai > > Suggested-by: Fāng-ruì Sòng > > Tested-by: Luis Lozano > > Tested-by: Manoj Gupta > > Acked-by: Kees Cook > > Cc: stable@vger.kernel.org > > Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=add44f8d5c5c05e08b11e033127a744d61c26aee > > Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=1de778ed23ce7492c523d5850c6c6dbb34152655 > > Link: https://reviews.llvm.org/D79600 > > Link: https://bugs.chromium.org/p/chromium/issues/detail?id=1084760 > > Debugged-by: Luis Lozano > > Signed-off-by: Nick Desaulniers > > Signed-off-by: Kees Cook > > --- > > include/asm-generic/vmlinux.lds.h | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h > > index 2593957f6e8b..af5211ca857c 100644 > > --- a/include/asm-generic/vmlinux.lds.h > > +++ b/include/asm-generic/vmlinux.lds.h > > @@ -561,7 +561,10 @@ > > */ > > #define TEXT_TEXT \ > > ALIGN_FUNCTION(); \ > > - *(.text.hot TEXT_MAIN .text.fixup .text.unlikely) \ > > + *(.text.hot .text.hot.*) \ > > + *(TEXT_MAIN .text.fixup) \ > > + *(.text.unlikely .text.unlikely.*) \ > > + *(.text.unknown .text.unknown.*) \ > > NOINSTR_TEXT \ > > *(.text..refcount) \ > > *(.ref.text) \ > > -- > > 2.25.1 > > > > This also changes the ordering to place all hot resp unlikely sections separate > from other text, while currently it places the hot/unlikely bits of each file > together with the rest of the code in that file. That seems like a reasonable Oh, hmm, yes, we aren't explicitly using SORT() here. Does that mean the input sections were entirely be ordered in compilation unit link order, even in the case of orphan sections? (And I think either way, the answer isn't the same between bfd and lld.) I actually thought the like-named input sections were collected together first with lld, but bfd strictly appended to the output section. I guess it's time for me to stare at -M output from ld... Regardless, this patch is attempting to fix the problem where bfd and lld lay out the orphans differently (as mentioned above, lld seems to sort them in a way that is not strictly appended, and bfd seems to sort them strictly appended). In the case of being appended to the .text output section, this would cause boot failures due to _etext not covering the resulting sections (which this[1] also encountered and fixed to be more robust for such appended collection -- that series actually _depends_ on orphan handling doing the appending, because there is no current way to map wildcard input sections to their own separate output sections). > change and should be mentioned in the commit message. > > However, the history of their being together comes from > > 9bebe9e5b0f3 ("kbuild: Fix .text.unlikely placement") > > which seems to indicate there was some problem with having them separated out, > although I don't quite understand what the issue was from the commit message. Looking at this again, I actually wonder if we have bigger issues here with dead code elimination: #ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION #define TEXT_MAIN .text .text.[0-9a-zA-Z_]* ... that would catch: .text.hot .text.fixup .text.unlikely and .text.unknown but not .text.hot.*, etc (i.e. the third dot isn't matched, which is, I assume, why Clang switched to adding a trailing dot). However, this patch lists .text.hot .text.hot.* first, so they'd get pulled to the front correctly, but the trailing ones (with 2 dots) would not, since they'd match the TEXT_MAIN wildcard first. (This problem actually existed before this patch too, and is not the fault of 9bebe9e5b0f3, but rather the addition of TEXT_MAIN, which could potentially match .text.unlikely and .text.fixup) Unless I'm totally wrong and the bfd docs don't match the behavior? e.g. if I have a link order of ".foo.before", ".foo.after", and ".foo.middle", and this rule: .foo : { *(.foo.before .foo.* .foo.after) } do I get this (first match): .foo.before .foo.after .foo.middle or (most specific match): .foo.before .foo.middle .foo.after ? As I said, now that I'm able to better articulate these questions, I'll go get answers from -M output. :) Perhaps we need to fix TEXT_MAIN not TEXT_TEXT? TEXT_TEXT is for collecting .text, .text.[^\.]* and *.text, where, effectively, .text and .text[^\.]* are defined by TEXT_MAIN. i.e. adding 3-dot "text" input sections needs to likely be included in TEXT_MAIN Anyway, I'll keep looking at this... (In the meantime, perhaps we can take Arvind's series, and the earlier portions of the orphan series where asm-generic/vmlinux.lds.h and other things are cleaned up...) -Kees [1] https://lore.kernel.org/lkml/20200717170008.5949-6-kristen@linux.intel.com/ -- Kees Cook 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 X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DDA57C433DF for ; Sat, 1 Aug 2020 06:20:01 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9C17720725 for ; Sat, 1 Aug 2020 06:20:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="wdXdprQi"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="KxKgPZ44" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9C17720725 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=yGtkz4CHyx5eB8iBAMq5Vavf/hvxkX9/nCOuaWFwjoI=; b=wdXdprQiAa2BlgKLNG48bRQVS PiPdnLXvm7O9I96AaHt9Du3lpV+jiMf9BeqPejuqt6MwIjh1r7CaHz36neIIr0ng3ZI0tuH2P27Oz leJGRlfITKMWGFn2UJ5AE1fJnDSIWXfv68BeowR/vjnfGF/3HxSdZtYQH5Sa3Q4bfEzSYBD/rs423 FgMNfE8gnuJJ/1o5EMavXdW2ZRF+Y4WXrQmzNAsI8Mi093aI9Ga9g9tX9Oo/olgu0g1EZBwU9Cykz y3Yk6Ai33feMtd2rjFTVDOdJ9sXxSxswuiL6g5fxD/Q1IEOmRtLA9haHXvw+b0MfG7b5nh2hTWvZb KLkJpI36w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1kqS-0005lZ-OD; Sat, 01 Aug 2020 06:18:12 +0000 Received: from mail-pg1-x541.google.com ([2607:f8b0:4864:20::541]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1kqP-0005jw-FD for linux-arm-kernel@lists.infradead.org; Sat, 01 Aug 2020 06:18:10 +0000 Received: by mail-pg1-x541.google.com with SMTP id m22so17112488pgv.9 for ; Fri, 31 Jul 2020 23:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=0Z19kOEJIEx9Zh1BTPeu+eub/GMK1VCMfldmZLSebVY=; b=KxKgPZ44MDuEzDzKcjvBPoOvvk6mFI7inQltWTO8STKjk+OTuM4IBFfbBTfcRxrBx9 Hv5LeqEqioFXqlilO6cmcV/9iIS7fSnVqceIhVcwVpR5Sc2SSjnksftHrADfcD5rwVsk B8Kq5NsEciksAOV8kLa0BY0Jpr9pgfCEQ46cY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=0Z19kOEJIEx9Zh1BTPeu+eub/GMK1VCMfldmZLSebVY=; b=TTlTMCVEQhfJvahrp7SOqzF5C1fdbXCD3aImd6YJvAvOPvn2FI1NgupMG48LBxbKL6 Sz2rG+bfi9k3ykU2ecmd1BZ7RJKXDsIABqwA5j3dhr4jiw/JlGU1WIpxLf+bsLTgFsdz XmKqRjRG7IjCyQNOSnpYAcJ/Wi3vrLEuBVTOyz+mziBH7djRk5/Gmsj6waGaY4RPPcq5 aIs0xuTuV18q72qvWmT4jK/b7r/HQcuo80Vu04T5MXM6BIjbFARs0cV2b1Av7ZFuxpCm mOvjY762OfFBrwMHJNmi6lGSZTkyNBeKjeyYfcSy/aJQv2eHsT7RGD6TiPSYh0CUljgS p/Zg== X-Gm-Message-State: AOAM5318HPKyLHJoYiLYqlbERfzjzzUL9U8UjmTbV11BUv7Gf2vW7F8L uqJ5hYT7IHsqWVQMt665cytntg== X-Google-Smtp-Source: ABdhPJx5AY+53D/D5aAfJwgIaGzvtgD0uJizQHS7B/hV1cIUoOKvZS+VpnFwSKDmIBEMYUOWOrqC8A== X-Received: by 2002:aa7:94bd:: with SMTP id a29mr6882406pfl.280.1596262684343; Fri, 31 Jul 2020 23:18:04 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id 7sm12129236pgw.85.2020.07.31.23.18.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Jul 2020 23:18:03 -0700 (PDT) Date: Fri, 31 Jul 2020 23:18:02 -0700 From: Kees Cook To: Arvind Sankar Subject: Re: [PATCH v5 13/36] vmlinux.lds.h: add PGO and AutoFDO input sections Message-ID: <202007312237.4F385EB3@keescook> References: <20200731230820.1742553-1-keescook@chromium.org> <20200731230820.1742553-14-keescook@chromium.org> <20200801035128.GB2800311@rani.riverdale.lan> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200801035128.GB2800311@rani.riverdale.lan> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200801_021809_550541_F3E715A3 X-CRM114-Status: GOOD ( 44.97 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , linux-efi@vger.kernel.org, Catalin Marinas , Manoj Gupta , Kristen Carlson Accardi , Will Deacon , Thomas Gleixner , linux-arch@vger.kernel.org, Andi Kleen , =?utf-8?B?RsSBbmctcnXDrCBTw7JuZw==?= , Masahiro Yamada , x86@kernel.org, Russell King , Ard Biesheuvel , clang-built-linux@googlegroups.com, Ingo Molnar , Luis Lozano , Borislav Petkov , Arnd Bergmann , Jian Cai , Nathan Chancellor , Peter Collingbourne , linux-arm-kernel@lists.infradead.org, Michal Marek , Nick Desaulniers , linux-kernel@vger.kernel.org, stable@vger.kernel.org, James Morse Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gRnJpLCBKdWwgMzEsIDIwMjAgYXQgMTE6NTE6MjhQTSAtMDQwMCwgQXJ2aW5kIFNhbmthciB3 cm90ZToKPiBPbiBGcmksIEp1bCAzMSwgMjAyMCBhdCAwNDowNzo1N1BNIC0wNzAwLCBLZWVzIENv b2sgd3JvdGU6Cj4gPiBGcm9tOiBOaWNrIERlc2F1bG5pZXJzIDxuZGVzYXVsbmllcnNAZ29vZ2xl LmNvbT4KPiA+IAo+ID4gQmFzaWNhbGx5LCBjb25zaWRlciAudGV4dC57aG90fHVubGlrZWx5fHVu a25vd259LiogcGFydCBvZiAudGV4dCwgdG9vLgo+ID4gCj4gPiBXaGVuIGNvbXBpbGluZyB3aXRo IHByb2ZpbGluZyBpbmZvcm1hdGlvbiAoY29sbGVjdGVkIHZpYSBQR08KPiA+IGluc3RydW1lbnRh dGlvbnMgb3IgQXV0b0ZETyBzYW1wbGluZyksIENsYW5nIHdpbGwgc2VwYXJhdGUgY29kZSBpbnRv Cj4gPiAudGV4dC5ob3QsIC50ZXh0LnVubGlrZWx5LCBvciAudGV4dC51bmtub3duIHNlY3Rpb25z IGJhc2VkIG9uIHByb2ZpbGluZwo+ID4gaW5mb3JtYXRpb24uIEFmdGVyIEQ3OTYwMCAoY2xhbmct MTEpLCB0aGVzZSBzZWN0aW9ucyB3aWxsIGhhdmUgYQo+ID4gdHJhaWxpbmcgYC5gIHN1ZmZpeCwg aWUuICAudGV4dC5ob3QuLCAudGV4dC51bmxpa2VseS4sIC50ZXh0LnVua25vd24uLgo+ID4gCj4g PiBXaGVuIHVzaW5nIC1mZnVuY3Rpb24tc2VjdGlvbnMgdG9nZXRoZXIgd2l0aCBwcm9maWxpbmcg aW5mb21hdGlvbiwKPiA+IGVpdGhlciBleHBsaWNpdGx5IChGR0tBU0xSKSBvciBpbXBsaWNpdGx5 IChMVE8pLCBjb2RlIG1heSBiZSBwbGFjZWQgaW4KPiA+IHNlY3Rpb25zIGZvbGxvd2luZyB0aGUg Y29udmVudGlvbjoKPiA+IC50ZXh0LmhvdC48Zm9vPiwgLnRleHQudW5saWtlbHkuPGJhcj4sIC50 ZXh0LnVua25vd24uPGJhej4KPiA+IHdoZXJlIDxmb28+LCA8YmFyPiwgYW5kIDxiYXo+IGFyZSBm dW5jdGlvbnMuICAoVGhpcyBwcm9kdWNlcyBvbmUgc2VjdGlvbgo+ID4gcGVyIGZ1bmN0aW9uOyB3 ZSBnZW5lcmFsbHkgdHJ5IHRvIG1lcmdlIHRoZXNlIGFsbCBiYWNrIHZpYSBsaW5rZXIgc2NyaXB0 Cj4gPiBzbyB0aGF0IHdlIGRvbid0IGhhdmUgNTBrIHNlY3Rpb25zKS4KPiA+IAo+ID4gRm9yIHRo ZSBhYm92ZSBjYXNlcywgd2UgbmVlZCB0byB0ZWFjaCBvdXIgbGlua2VyIHNjcmlwdHMgdGhhdCBz dWNoCj4gPiBzZWN0aW9ucyBtaWdodCBleGlzdCBhbmQgdGhhdCB3ZSdkIGV4cGxpY2l0bHkgbGlr ZSB0aGVtIGdyb3VwZWQKPiA+IHRvZ2V0aGVyLCBvdGhlcndpc2Ugd2UgY2FuIHdpbmQgdXAgd2l0 aCBjb2RlIG91dHNpZGUgb2YgdGhlCj4gPiBfc3RleHQvX2V0ZXh0IGJvdW5kYXJpZXMgdGhhdCBt aWdodCBub3QgYmUgbWFwcGVkIHByb3Blcmx5IGZvciBzb21lCj4gPiBhcmNoaXRlY3R1cmVzLCBy ZXN1bHRpbmcgaW4gYm9vdCBmYWlsdXJlcy4KPiA+IAo+ID4gSWYgdGhlIGxpbmtlciBzY3JpcHQg aXMgbm90IHRvbGQgYWJvdXQgcG9zc2libGUgaW5wdXQgc2VjdGlvbnMsIHRoZW4KPiA+IHdoZXJl IHRoZSBzZWN0aW9uIGlzIHBsYWNlZCBhcyBvdXRwdXQgaXMgYSBoZXVyaXN0aWMtbGFpZGVuIG1l c3MgdGhhdCdzCj4gPiBub24tcG9ydGFibGUgYmV0d2VlbiBsaW5rZXJzIChpZS4gQkZEIGFuZCBM TEQpLCBhbmQgaGFzIHJlc3VsdGVkIGluIG1hbnkKPiA+IGhhcmQgdG8gZGVidWcgYnVncy4gIEtl ZXMgQ29vayBpcyB3b3JraW5nIG9uIGNsZWFuaW5nIHRoaXMgdXAgYnkgYWRkaW5nCj4gPiAtLW9y cGhhbi1oYW5kbGluZz13YXJuIGxpbmtlciBmbGFnIHVzZWQgaW4gQVJDSD1wb3dlcnBjIHRvIGFk ZGl0aW9uYWwKPiA+IGFyY2hpdGVjdHVyZXMuIEluIHRoZSBjYXNlIG9mIGxpbmtlciBzY3JpcHRz LCBib3Jyb3dpbmcgZnJvbSB0aGUgWmVuIG9mCj4gPiBQeXRob246IGV4cGxpY2l0IGlzIGJldHRl ciB0aGFuIGltcGxpY2l0Lgo+ID4gCj4gPiBBbHNvLCBsZC5iZmQncyBpbnRlcm5hbCBsaW5rZXIg c2NyaXB0IGNvbnNpZGVycyAudGV4dC5ob3QgQU5ECj4gPiAudGV4dC5ob3QuKiB0byBiZSBwYXJ0 IG9mIC50ZXh0LCBhcyB3ZWxsIGFzIC50ZXh0LnVubGlrZWx5IGFuZAo+ID4gLnRleHQudW5saWtl bHkuKi4gSSBkaWRuJ3Qgc2VlIHN1cHBvcnQgZm9yIC50ZXh0LnVua25vd24uKiwgYW5kIGRpZG4n dAo+ID4gc2VlIENsYW5nIHByb2R1Y2luZyBzdWNoIGNvZGUgaW4gb3VyIGtlcm5lbCBidWlsZHMs IGJ1dCBJIHNlZSBjb2RlIGluCj4gPiBMTFZNIHRoYXQgY2FuIHByb2R1Y2Ugc3VjaCBzZWN0aW9u IG5hbWVzIGlmIHByb2ZpbGluZyBpbmZvcm1hdGlvbiBpcwo+ID4gbWlzc2luZy4gVGhhdCBtYXkg cG9pbnQgdG8gYSBsYXJnZXIgaXNzdWUgd2l0aCBnZW5lcmF0aW5nIG9yIGNvbGxlY3RpbmcKPiA+ IHByb2ZpbGVzLCBidXQgSSB3b3VsZCBtdWNoIHJhdGhlciBiZSBzYWZlIGFuZCBleHBsaWNpdCB0 aGFuIGhhdmUgdG8KPiA+IGRlYnVnIHlldCBhbm90aGVyIGlzc3VlIHJlbGF0ZWQgdG8gb3JwaGFu IHNlY3Rpb24gcGxhY2VtZW50Lgo+ID4gCj4gPiBSZXBvcnRlZC1ieTogSmlhbiBDYWkgPGppYW5j YWlAZ29vZ2xlLmNvbT4KPiA+IFN1Z2dlc3RlZC1ieTogRsSBbmctcnXDrCBTw7JuZyA8bWFza3Jh eUBnb29nbGUuY29tPgo+ID4gVGVzdGVkLWJ5OiBMdWlzIExvemFubyA8bGxvemFub0Bnb29nbGUu Y29tPgo+ID4gVGVzdGVkLWJ5OiBNYW5vaiBHdXB0YSA8bWFub2pndXB0YUBnb29nbGUuY29tPgo+ ID4gQWNrZWQtYnk6IEtlZXMgQ29vayA8a2Vlc2Nvb2tAY2hyb21pdW0ub3JnPgo+ID4gQ2M6IHN0 YWJsZUB2Z2VyLmtlcm5lbC5vcmcKPiA+IExpbms6IGh0dHBzOi8vc291cmNld2FyZS5vcmcvZ2l0 Lz9wPWJpbnV0aWxzLWdkYi5naXQ7YT1jb21taXRkaWZmO2g9YWRkNDRmOGQ1YzVjMDVlMDhiMTFl MDMzMTI3YTc0NGQ2MWMyNmFlZQo+ID4gTGluazogaHR0cHM6Ly9zb3VyY2V3YXJlLm9yZy9naXQv P3A9YmludXRpbHMtZ2RiLmdpdDthPWNvbW1pdGRpZmY7aD0xZGU3NzhlZDIzY2U3NDkyYzUyM2Q1 ODUwYzZjNmRiYjM0MTUyNjU1Cj4gPiBMaW5rOiBodHRwczovL3Jldmlld3MubGx2bS5vcmcvRDc5 NjAwCj4gPiBMaW5rOiBodHRwczovL2J1Z3MuY2hyb21pdW0ub3JnL3AvY2hyb21pdW0vaXNzdWVz L2RldGFpbD9pZD0xMDg0NzYwCj4gPiBEZWJ1Z2dlZC1ieTogTHVpcyBMb3phbm8gPGxsb3phbm9A Z29vZ2xlLmNvbT4KPiA+IFNpZ25lZC1vZmYtYnk6IE5pY2sgRGVzYXVsbmllcnMgPG5kZXNhdWxu aWVyc0Bnb29nbGUuY29tPgo+ID4gU2lnbmVkLW9mZi1ieTogS2VlcyBDb29rIDxrZWVzY29va0Bj aHJvbWl1bS5vcmc+Cj4gPiAtLS0KPiA+ICBpbmNsdWRlL2FzbS1nZW5lcmljL3ZtbGludXgubGRz LmggfCA1ICsrKystCj4gPiAgMSBmaWxlIGNoYW5nZWQsIDQgaW5zZXJ0aW9ucygrKSwgMSBkZWxl dGlvbigtKQo+ID4gCj4gPiBkaWZmIC0tZ2l0IGEvaW5jbHVkZS9hc20tZ2VuZXJpYy92bWxpbnV4 Lmxkcy5oIGIvaW5jbHVkZS9hc20tZ2VuZXJpYy92bWxpbnV4Lmxkcy5oCj4gPiBpbmRleCAyNTkz OTU3ZjZlOGIuLmFmNTIxMWNhODU3YyAxMDA2NDQKPiA+IC0tLSBhL2luY2x1ZGUvYXNtLWdlbmVy aWMvdm1saW51eC5sZHMuaAo+ID4gKysrIGIvaW5jbHVkZS9hc20tZ2VuZXJpYy92bWxpbnV4Lmxk cy5oCj4gPiBAQCAtNTYxLDcgKzU2MSwxMCBAQAo+ID4gICAqLwo+ID4gICNkZWZpbmUgVEVYVF9U RVhUCQkJCQkJCVwKPiA+ICAJCUFMSUdOX0ZVTkNUSU9OKCk7CQkJCQlcCj4gPiAtCQkqKC50ZXh0 LmhvdCBURVhUX01BSU4gLnRleHQuZml4dXAgLnRleHQudW5saWtlbHkpCVwKPiA+ICsJCSooLnRl eHQuaG90IC50ZXh0LmhvdC4qKQkJCQlcCj4gPiArCQkqKFRFWFRfTUFJTiAudGV4dC5maXh1cCkJ CQkJXAo+ID4gKwkJKigudGV4dC51bmxpa2VseSAudGV4dC51bmxpa2VseS4qKQkJCVwKPiA+ICsJ CSooLnRleHQudW5rbm93biAudGV4dC51bmtub3duLiopCQkJXAo+ID4gIAkJTk9JTlNUUl9URVhU CQkJCQkJXAo+ID4gIAkJKigudGV4dC4ucmVmY291bnQpCQkJCQlcCj4gPiAgCQkqKC5yZWYudGV4 dCkJCQkJCQlcCj4gPiAtLSAKPiA+IDIuMjUuMQo+ID4gCj4gCj4gVGhpcyBhbHNvIGNoYW5nZXMg dGhlIG9yZGVyaW5nIHRvIHBsYWNlIGFsbCBob3QgcmVzcCB1bmxpa2VseSBzZWN0aW9ucyBzZXBh cmF0ZQo+IGZyb20gb3RoZXIgdGV4dCwgd2hpbGUgY3VycmVudGx5IGl0IHBsYWNlcyB0aGUgaG90 L3VubGlrZWx5IGJpdHMgb2YgZWFjaCBmaWxlCj4gdG9nZXRoZXIgd2l0aCB0aGUgcmVzdCBvZiB0 aGUgY29kZSBpbiB0aGF0IGZpbGUuIFRoYXQgc2VlbXMgbGlrZSBhIHJlYXNvbmFibGUKCk9oLCBo bW0sIHllcywgd2UgYXJlbid0IGV4cGxpY2l0bHkgdXNpbmcgU09SVCgpIGhlcmUuIERvZXMgdGhh dCBtZWFuIHRoZQppbnB1dCBzZWN0aW9ucyB3ZXJlIGVudGlyZWx5IGJlIG9yZGVyZWQgaW4gY29t cGlsYXRpb24gdW5pdCBsaW5rIG9yZGVyLApldmVuIGluIHRoZSBjYXNlIG9mIG9ycGhhbiBzZWN0 aW9ucz8gKEFuZCBJIHRoaW5rIGVpdGhlciB3YXksIHRoZSBhbnN3ZXIKaXNuJ3QgdGhlIHNhbWUg YmV0d2VlbiBiZmQgYW5kIGxsZC4pIEkgYWN0dWFsbHkgdGhvdWdodCB0aGUgbGlrZS1uYW1lZApp bnB1dCBzZWN0aW9ucyB3ZXJlIGNvbGxlY3RlZCB0b2dldGhlciBmaXJzdCB3aXRoIGxsZCwgYnV0 IGJmZCBzdHJpY3RseQphcHBlbmRlZCB0byB0aGUgb3V0cHV0IHNlY3Rpb24uIEkgZ3Vlc3MgaXQn cyB0aW1lIGZvciBtZSB0byBzdGFyZSBhdCAtTQpvdXRwdXQgZnJvbSBsZC4uLgoKUmVnYXJkbGVz cywgdGhpcyBwYXRjaCBpcyBhdHRlbXB0aW5nIHRvIGZpeCB0aGUgcHJvYmxlbSB3aGVyZSBiZmQg YW5kIGxsZApsYXkgb3V0IHRoZSBvcnBoYW5zIGRpZmZlcmVudGx5IChhcyBtZW50aW9uZWQgYWJv dmUsIGxsZCBzZWVtcyB0byBzb3J0CnRoZW0gaW4gYSB3YXkgdGhhdCBpcyBub3Qgc3RyaWN0bHkg YXBwZW5kZWQsIGFuZCBiZmQgc2VlbXMgdG8gc29ydCB0aGVtCnN0cmljdGx5IGFwcGVuZGVkKS4g SW4gdGhlIGNhc2Ugb2YgYmVpbmcgYXBwZW5kZWQgdG8gdGhlIC50ZXh0IG91dHB1dApzZWN0aW9u LCB0aGlzIHdvdWxkIGNhdXNlIGJvb3QgZmFpbHVyZXMgZHVlIHRvIF9ldGV4dCBub3QgY292ZXJp bmcgdGhlCnJlc3VsdGluZyBzZWN0aW9ucyAod2hpY2ggdGhpc1sxXSBhbHNvIGVuY291bnRlcmVk IGFuZCBmaXhlZCB0byBiZSBtb3JlCnJvYnVzdCBmb3Igc3VjaCBhcHBlbmRlZCBjb2xsZWN0aW9u IC0tIHRoYXQgc2VyaWVzIGFjdHVhbGx5IF9kZXBlbmRzXyBvbgpvcnBoYW4gaGFuZGxpbmcgZG9p bmcgdGhlIGFwcGVuZGluZywgYmVjYXVzZSB0aGVyZSBpcyBubyBjdXJyZW50IHdheQp0byBtYXAg d2lsZGNhcmQgaW5wdXQgc2VjdGlvbnMgdG8gdGhlaXIgb3duIHNlcGFyYXRlIG91dHB1dCBzZWN0 aW9ucykuCgo+IGNoYW5nZSBhbmQgc2hvdWxkIGJlIG1lbnRpb25lZCBpbiB0aGUgY29tbWl0IG1l c3NhZ2UuCj4gCj4gSG93ZXZlciwgdGhlIGhpc3Rvcnkgb2YgdGhlaXIgYmVpbmcgdG9nZXRoZXIg Y29tZXMgZnJvbQo+IAo+ICAgOWJlYmU5ZTViMGYzICgia2J1aWxkOiBGaXggLnRleHQudW5saWtl bHkgcGxhY2VtZW50IikKPiAKPiB3aGljaCBzZWVtcyB0byBpbmRpY2F0ZSB0aGVyZSB3YXMgc29t ZSBwcm9ibGVtIHdpdGggaGF2aW5nIHRoZW0gc2VwYXJhdGVkIG91dCwKPiBhbHRob3VnaCBJIGRv bid0IHF1aXRlIHVuZGVyc3RhbmQgd2hhdCB0aGUgaXNzdWUgd2FzIGZyb20gdGhlIGNvbW1pdCBt ZXNzYWdlLgoKTG9va2luZyBhdCB0aGlzIGFnYWluLCBJIGFjdHVhbGx5IHdvbmRlciBpZiB3ZSBo YXZlIGJpZ2dlciBpc3N1ZXMgaGVyZQp3aXRoIGRlYWQgY29kZSBlbGltaW5hdGlvbjoKCiNpZmRl ZiBDT05GSUdfTERfREVBRF9DT0RFX0RBVEFfRUxJTUlOQVRJT04KI2RlZmluZSBURVhUX01BSU4g LnRleHQgLnRleHQuWzAtOWEtekEtWl9dKgouLi4KCnRoYXQgd291bGQgY2F0Y2g6IC50ZXh0Lmhv dCAudGV4dC5maXh1cCAudGV4dC51bmxpa2VseSBhbmQgLnRleHQudW5rbm93bgpidXQgbm90IC50 ZXh0LmhvdC4qLCBldGMgKGkuZS4gdGhlIHRoaXJkIGRvdCBpc24ndCBtYXRjaGVkLCB3aGljaCBp cywKSSBhc3N1bWUsIHdoeSBDbGFuZyBzd2l0Y2hlZCB0byBhZGRpbmcgYSB0cmFpbGluZyBkb3Qp LiBIb3dldmVyLCB0aGlzCnBhdGNoIGxpc3RzIC50ZXh0LmhvdCAudGV4dC5ob3QuKiBmaXJzdCwg c28gdGhleSdkIGdldCBwdWxsZWQgdG8gdGhlCmZyb250IGNvcnJlY3RseSwgYnV0IHRoZSB0cmFp bGluZyBvbmVzICh3aXRoIDIgZG90cykgd291bGQgbm90LCBzaW5jZQp0aGV5J2QgbWF0Y2ggdGhl IFRFWFRfTUFJTiB3aWxkY2FyZCBmaXJzdC4gKFRoaXMgcHJvYmxlbSBhY3R1YWxseSBleGlzdGVk CmJlZm9yZSB0aGlzIHBhdGNoIHRvbywgYW5kIGlzIG5vdCB0aGUgZmF1bHQgb2YgOWJlYmU5ZTVi MGYzLCBidXQgcmF0aGVyCnRoZSBhZGRpdGlvbiBvZiBURVhUX01BSU4sIHdoaWNoIGNvdWxkIHBv dGVudGlhbGx5IG1hdGNoIC50ZXh0LnVubGlrZWx5CmFuZCAudGV4dC5maXh1cCkKClVubGVzcyBJ J20gdG90YWxseSB3cm9uZyBhbmQgdGhlIGJmZCBkb2NzIGRvbid0IG1hdGNoIHRoZSBiZWhhdmlv cj8gZS5nLgppZiBJIGhhdmUgYSBsaW5rIG9yZGVyIG9mICIuZm9vLmJlZm9yZSIsICIuZm9vLmFm dGVyIiwgYW5kICIuZm9vLm1pZGRsZSIsCmFuZCB0aGlzIHJ1bGU6CgouZm9vIDogeyAqKC5mb28u YmVmb3JlIC5mb28uKiAuZm9vLmFmdGVyKSB9CgpkbyBJIGdldCB0aGlzIChmaXJzdCBtYXRjaCk6 CgoJLmZvby5iZWZvcmUKCS5mb28uYWZ0ZXIKCS5mb28ubWlkZGxlCgpvciAobW9zdCBzcGVjaWZp YyBtYXRjaCk6CgoJLmZvby5iZWZvcmUKCS5mb28ubWlkZGxlCgkuZm9vLmFmdGVyCgo/CgpBcyBJ IHNhaWQsIG5vdyB0aGF0IEknbSBhYmxlIHRvIGJldHRlciBhcnRpY3VsYXRlIHRoZXNlIHF1ZXN0 aW9ucywgSSdsbApnbyBnZXQgYW5zd2VycyBmcm9tIC1NIG91dHB1dC4gOikKClBlcmhhcHMgd2Ug bmVlZCB0byBmaXggVEVYVF9NQUlOIG5vdCBURVhUX1RFWFQ/IFRFWFRfVEVYVCBpcyBmb3IKY29s bGVjdGluZyAudGV4dCwgLnRleHQuW15cLl0qIGFuZCAqLnRleHQsIHdoZXJlLCBlZmZlY3RpdmVs eSwKLnRleHQgYW5kIC50ZXh0W15cLl0qIGFyZSBkZWZpbmVkIGJ5IFRFWFRfTUFJTi4gaS5lLiBh ZGRpbmcgMy1kb3QgInRleHQiCmlucHV0IHNlY3Rpb25zIG5lZWRzIHRvIGxpa2VseSBiZSBpbmNs dWRlZCBpbiBURVhUX01BSU4KCkFueXdheSwgSSdsbCBrZWVwIGxvb2tpbmcgYXQgdGhpcy4uLgoK KEluIHRoZSBtZWFudGltZSwgcGVyaGFwcyB3ZSBjYW4gdGFrZSBBcnZpbmQncyBzZXJpZXMsIGFu ZCB0aGUgZWFybGllcgpwb3J0aW9ucyBvZiB0aGUgb3JwaGFuIHNlcmllcyB3aGVyZSBhc20tZ2Vu ZXJpYy92bWxpbnV4Lmxkcy5oIGFuZCBvdGhlcgp0aGluZ3MgYXJlIGNsZWFuZWQgdXAuLi4pCgot S2VlcwoKWzFdIGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL2xrbWwvMjAyMDA3MTcxNzAwMDguNTk0 OS02LWtyaXN0ZW5AbGludXguaW50ZWwuY29tLwoKLS0gCktlZXMgQ29vawoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWls aW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0 cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo=