From patchwork Fri Aug 21 19:42:47 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 11730393 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 39FC013B1 for ; Fri, 21 Aug 2020 19:47:07 +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 12E8C2072D for ; Fri, 21 Aug 2020 19:47:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="K4k1fojl"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="S9JWqqSo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 12E8C2072D 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+patchwork-linux-arm=patchwork.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:MIME-Version:References:In-Reply-To:Message-Id:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=lpsbJCPRVZValQmlegkRGF9han7qShnzBAGg1PJ7Kuk=; b=K4k1fojlTHIRrpHhorfiDKV+K o0C6jL8UuvK11flPTchdB/ms4DzbzaFVqI1DzX3ufawmqjpJLOgpj7RyDHIhTqGJ+Q0kTVceonyJf aEgilM5QIVZ2PIo48Z4+NIvvrwx50gmnsxgF2cefH12/Uy38flNCP85A4reyU+N20NtmJa+2zLIbV wy9AbwTcxiswWHWbVMND3hFORndKQqmQ/pVscxmKXA5ZqvOZ4bTonQKx1k5ptniG+YGRk7F9nDKPz DcP03APQTNo9OrYmKmyVv7dfmDcZ5KhwEim2oOThGrD8epkOQiS7ziWKLkN5Hjeite8EdmbgC8okj aUj5r7bkQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k9CyD-0006jI-AR; Fri, 21 Aug 2020 19:45:02 +0000 Received: from mail-pl1-x642.google.com ([2607:f8b0:4864:20::642]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k9Cxe-0006VN-NU for linux-arm-kernel@lists.infradead.org; Fri, 21 Aug 2020 19:44:31 +0000 Received: by mail-pl1-x642.google.com with SMTP id f5so1334404plr.9 for ; Fri, 21 Aug 2020 12:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=LhHa8hwizWicyR7AmABsSaI963QK2ejKgNvGzEzQJyI=; b=S9JWqqSou1s/FK9u3DQ4o9uu0Z66hNrndmRM9lwRys0IRRdCU3reoSB3x/0i4D3/0d FE38SPzh4Sjdcmnpux/wEu2YEvs49KaQ4x96TdKBVxMC1MQo/Pu6aF3uTjn2T4WoNN1/ 69NCo9CYct3Ga+OFZvqV0/uxV0gjNFTPm/uUo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=LhHa8hwizWicyR7AmABsSaI963QK2ejKgNvGzEzQJyI=; b=gIpX14Fu89Y+env0qxeqQ77o+VknexdPUNXJX845gWdG9wZV896IPrlEwF6YE+8nL3 CGwiJvBeMvVHSgu5QmeaUx7bjvOQYG8Wj+IB6vOuegcbV+Xegg0GDjfC9c3DmvwYn04x SY02QlmRgOV0KR8RVtgkV2WLkegXPvwZs3n77Yo/vTE/qG5Flfcvbm4uBWLzvZeXQFSp LVHYZG0fcqGucG8EiSqZPzj7OTvnXpikCDyxqgNU50qMvmZfEDBZrZAnT/6xugzH0RBE lZbuDVGKlQr34ONAQPVUgs7J+eF+63SUXt1kvtDvNQoz2Dt7GwU4MTAVcmC0+DuawqKI yg/Q== X-Gm-Message-State: AOAM531gvMDOjM9PADoMhl6yMc8mf/BIqr80A5X39uIxuexyuV3HuL4C Lw1GsygNr5iHIa4r1KR7Y/JWKg== X-Google-Smtp-Source: ABdhPJzWv+Ua2gk2lyj7ptkVCQDZcrq9EuhQmtA+I5dIDb9MoFHSNp7AHZuTqGfhtxhz0zpt9GJ9mA== X-Received: by 2002:a17:902:b70e:: with SMTP id d14mr3365610pls.253.1598039065065; Fri, 21 Aug 2020 12:44:25 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id a193sm3460814pfa.105.2020.08.21.12.44.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Aug 2020 12:44:21 -0700 (PDT) From: Kees Cook To: Ingo Molnar Subject: [PATCH v6 06/29] vmlinux.lds.h: add PGO and AutoFDO input sections Date: Fri, 21 Aug 2020 12:42:47 -0700 Message-Id: <20200821194310.3089815-7-keescook@chromium.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200821194310.3089815-1-keescook@chromium.org> References: <20200821194310.3089815-1-keescook@chromium.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200821_154426_804436_9FE9E0F6 X-CRM114-Status: GOOD ( 19.69 ) X-Spam-Score: -0.2 (/) X-Spam-Report: SpamAssassin version 3.4.4 on merlin.infradead.org summary: Content analysis details: (-0.2 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2607:f8b0:4864:20:0:0:0:642 listed in] [list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.0 DKIMWL_WL_HIGH DKIMwl.org - Whitelisted High sender 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 , Arvind Sankar , Manoj Gupta , Ard Biesheuvel , linux-arch@vger.kernel.org, =?utf-8?b?RsSBbmctcnXDrCBTw7JuZw==?= , Masahiro Yamada , x86@kernel.org, Russell King , clang-built-linux@googlegroups.com, Ingo Molnar , Luis Lozano , Borislav Petkov , Kees Cook , Arnd Bergmann , Jian Cai , Nathan Chancellor , Peter Collingbourne , linux-arm-kernel@lists.infradead.org, Nick Desaulniers , linux-kernel@vger.kernel.org, stable@vger.kernel.org, James Morse Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org 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 98d013dcc11a..91dcfb91ac45 100644 --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -581,7 +581,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) \