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=-9.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 A5811C43461 for ; Thu, 3 Sep 2020 23:34:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7ACBE2078E for ; Thu, 3 Sep 2020 23:34:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="YPszo9Kh" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729278AbgICXeS (ORCPT ); Thu, 3 Sep 2020 19:34:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35654 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728134AbgICXeN (ORCPT ); Thu, 3 Sep 2020 19:34:13 -0400 Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 79110C061247 for ; Thu, 3 Sep 2020 16:34:12 -0700 (PDT) Received: by mail-pg1-x544.google.com with SMTP id 5so3359239pgl.4 for ; Thu, 03 Sep 2020 16:34:12 -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:in-reply-to; bh=4fH9b479jfHonzzWwhHXw+3tbSLJMOM3KzAo1jerfBs=; b=YPszo9KhuFfseZZDaTsKlonChjdXxtUXRJ77uUarXLsjA//VSNUWKlHR5XkQJIWVHO xnk2Vsy5goIfOC2m7gmQ9XrZQN7PqsFGCZA8oDkEbzUkaE3/QfY+PiLiJqkH+J0hk3OC Toju6SdmLUVUzrlPYiCuOWqN4sYDQ5u5Bc+CM= 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:in-reply-to; bh=4fH9b479jfHonzzWwhHXw+3tbSLJMOM3KzAo1jerfBs=; b=MvvIHqRPt4BM31mVMkn9i3FR6XBKfj3FdC7nkWZP13T36QwzfjYQ2f6KcA6fXM3k3/ eP4G9axqmETvyLZj2uEnt2udyUQ5LVbdAvB4ZKm6+SF0FpnJM/+G9iE1lUZ0cszho+0O vzsc4iUqHuHeewCnGIbdj8r/QtZ20tEBOIOomwrsKzjCS7GuCeIK8yAn31vjTO/F02k9 ZrMz1JogauvKIDktCt7z9v4yYn/HSOPXOUuzLldZpj+nxV6PnWZIePzZZyKPUPVLJfXc 7gRT7tppZfnvA25C9B8Nzz1et1ZPDlb4xTL5dRfFo0Wz55OFacbzvHuCwr58iBpUi3Yk NkRg== X-Gm-Message-State: AOAM531Z9raPxMcA3698w37fqC6x96YFilW/DPG4o1KyOf5BIeKCgc6V MeOMSJbbsvc1tS4FPJGyda9u3g== X-Google-Smtp-Source: ABdhPJxjnSu+yLHWWJfiy7xRvCiUUgHTAGNwM2UhSXChmSRbPFQ4p7gsIG3bTSR63P416rAUVvCDEw== X-Received: by 2002:aa7:9707:: with SMTP id a7mr6021587pfg.257.1599176051457; Thu, 03 Sep 2020 16:34:11 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id my8sm3390805pjb.11.2020.09.03.16.34.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Sep 2020 16:34:10 -0700 (PDT) Date: Thu, 3 Sep 2020 16:34:09 -0700 From: Kees Cook To: Sami Tolvanen Cc: Masahiro Yamada , Will Deacon , Peter Zijlstra , Steven Rostedt , Greg Kroah-Hartman , "Paul E. McKenney" , Nick Desaulniers , clang-built-linux@googlegroups.com, kernel-hardening@lists.openwall.com, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH v2 00/28] Add support for Clang LTO Message-ID: <202009031557.4A233A17F1@keescook> References: <20200624203200.78870-1-samitolvanen@google.com> <20200903203053.3411268-1-samitolvanen@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200903203053.3411268-1-samitolvanen@google.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 03, 2020 at 01:30:25PM -0700, Sami Tolvanen wrote: > This patch series adds support for building x86_64 and arm64 kernels > with Clang's Link Time Optimization (LTO). Tested-by: Kees Cook FWIW, this gives me a happy booting x86 kernel: # cat /proc/version Linux version 5.9.0-rc3+ (kees@amarok) (clang version 12.0.0 (https://github.com/llvm/llvm-project.git db1ec04963cce70f2593e58cecac55f2e6accf52), LLD 12.0.0 (https://github.com/llvm/llvm-project.git db1ec04963cce70f2593e58cecac55f2e6accf52)) #1 SMP Thu Sep 3 15:54:14 PDT 2020 # zgrep 'LTO[_=]' /proc/config.gz CONFIG_LTO=y CONFIG_ARCH_SUPPORTS_LTO_CLANG=y CONFIG_ARCH_SUPPORTS_THINLTO=y CONFIG_THINLTO=y # CONFIG_LTO_NONE is not set CONFIG_LTO_CLANG=y I'd like to find a way to get this series landing sanely. It has dependencies on fixes/features in a few trees, and it looks like it's been difficult to keep forward momentum on LTO while trying to simultaneously chase changes in those trees, especially since it means no one care carry LTO in -next without shared branches. To that end, I'd like to find a way forward where Sami doesn't have to keep carrying a couple dozen patches. :) The fixes/features outside of, or partially overlapping, Masahiro's kbuild tree appear to be: [PATCH v2 01/28] x86/boot/compressed: Disable relocation relaxation [PATCH v2 02/28] x86/asm: Replace __force_order with memory clobber [PATCH v2 03/28] lib/string.c: implement stpcpy [PATCH v2 04/28] RAS/CEC: Fix cec_init() prototype [PATCH v2 05/28] objtool: Add a pass for generating __mcount_loc [PATCH v2 06/28] objtool: Don't autodetect vmlinux.o [PATCH v2 07/28] kbuild: add support for objtool mcount [PATCH v2 08/28] x86, build: use objtool mcount [PATCH v2 17/28] PCI: Fix PREL32 relocations for LTO [PATCH v2 20/28] efi/libstub: disable LTO [PATCH v2 21/28] drivers/misc/lkdtm: disable LTO for rodata.o [PATCH v2 22/28] arm64: export CC_USING_PATCHABLE_FUNCTION_ENTRY [PATCH v2 23/28] arm64: vdso: disable LTO [PATCH v2 24/28] KVM: arm64: disable LTO for the nVHE directory [PATCH v2 25/28] arm64: allow LTO_CLANG and THINLTO to be selected [PATCH v2 26/28] x86, vdso: disable LTO only for vDSO [PATCH v2 27/28] x86, relocs: Ignore L4_PAGE_OFFSET relocations [PATCH v2 28/28] x86, build: allow LTO_CLANG and THINLTO to be selected The distinctly kbuild patches are: [PATCH v2 09/28] kbuild: add support for Clang LTO [PATCH v2 10/28] kbuild: lto: fix module versioning [PATCH v2 11/28] kbuild: lto: postpone objtool [PATCH v2 12/28] kbuild: lto: limit inlining [PATCH v2 13/28] kbuild: lto: merge module sections [PATCH v2 14/28] kbuild: lto: remove duplicate dependencies from .mod files [PATCH v2 15/28] init: lto: ensure initcall ordering [PATCH v2 16/28] init: lto: fix PREL32 relocations [PATCH v2 18/28] modpost: lto: strip .lto from module names [PATCH v2 19/28] scripts/mod: disable LTO for empty.c Patch 3 is in -mm and I expect it will land in the next rc (I hope, since it's needed universally for Clang builds). Patch 4 is living in -tip, to appear shortly in -next, AFAICT? I would expect 1 and 2 to appear in -tip soon, but I'm not sure? For patches 5, 6, 7, and 8 I would expect them to normally go via -tip's objtool tree, but getting an Ack would let them land elsewhere. Patch 17 I'd expect to normally go via Bjorn's tree, but he's given an Ack so it can live elsewhere without surprises. :) Patches 19, 20, 21, 23, 24, 26 are all simple "just disable LTO" patches. This leaves 9-16 and 18. Patches 10, 12, 14, 16, and 18 seem mostly "mechanical" in nature, leaving the bulk of the review on patches 9, 11, 13, and 15. Masahiro, given the spread of dependent patches between 2 (or more?) -tip branches and -mm, how do you want to proceed? I wonder if it might be possible to create a shared branch to avoid merge headaches, and I (or -tip folks, or you) could carry patches 1-8 there so patches 9 and later could have a common base? Thanks! -- 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=-9.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 934FBC43461 for ; Thu, 3 Sep 2020 23:35:38 +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 518162078E for ; Thu, 3 Sep 2020 23:35:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="H2KfDsjm"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="YPszo9Kh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 518162078E 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=GgzN8RuW1Z0WjwjDH45V4eFRP0Ja+CB/JN5rBdyrfDM=; b=H2KfDsjmm7AspkO3EwayQuTpa YZx0Qkq7vl4NoUlC6n+el4XTKzNnJcYM58c/a0bfL+R2jDmKXmxnPIP+8Lthoer20z3FD6eq4q8Rr Ntw1tnFBw4HqaWtiYWA1GVMgKX6jGohxx6I2D1ulA9IFzZGgv3cSgy4B8jId1ZqRHv2nskaksD9J3 yY+2Xy77LsEndNiyx2HboEbly9yIAdOb/t9H6Te0mvHwQVxIOs5aLrPTQoys/RjSEm9M8sAauggzZ SChcsHnicRVUOxVsZCYBnTtCVKOMgoWEaB1fmfqbVf5uX9iiJPEK2abItQAJEweDKTHEOePyP1lx1 /7NX/EGQA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kDykC-0000Pk-On; Thu, 03 Sep 2020 23:34:16 +0000 Received: from mail-pg1-x544.google.com ([2607:f8b0:4864:20::544]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kDyk9-0000Os-PT for linux-arm-kernel@lists.infradead.org; Thu, 03 Sep 2020 23:34:14 +0000 Received: by mail-pg1-x544.google.com with SMTP id v15so3351598pgh.6 for ; Thu, 03 Sep 2020 16:34:13 -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:in-reply-to; bh=4fH9b479jfHonzzWwhHXw+3tbSLJMOM3KzAo1jerfBs=; b=YPszo9KhuFfseZZDaTsKlonChjdXxtUXRJ77uUarXLsjA//VSNUWKlHR5XkQJIWVHO xnk2Vsy5goIfOC2m7gmQ9XrZQN7PqsFGCZA8oDkEbzUkaE3/QfY+PiLiJqkH+J0hk3OC Toju6SdmLUVUzrlPYiCuOWqN4sYDQ5u5Bc+CM= 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:in-reply-to; bh=4fH9b479jfHonzzWwhHXw+3tbSLJMOM3KzAo1jerfBs=; b=AYhLUUnY6+Et1x7FLp0K9CF776eTD0A9asqrZS77p3jW1h4KaxZ5BVbP5WGMDvSCcB rOQHsqy5T0smlxCrG6tnB/qR5tMqi//vb+rkeW1g1Yidl6iO4/HqJ5EigqxYgg5OZdqp h5ZYGmj+T1DwHc+ZLdKExHiBeemPT7CXH4Qjz/Go/2cduQneSwcksOjyZPX2iejhnJRy iHTYiapDlxHX5IHou0Yvk6c5D2p2DUtE7l1WGD7w/DCk4PoW3f7Yl8icBSiiYKcIL+rj kRUiLf2TtIZxrSFs4prXFAWDYelm3S2rU+ew05MI+R6teTQPLsvCh2NQtvonuIUxEPqV DqDw== X-Gm-Message-State: AOAM53065MbxcQwP07JZLPtkt5fMgji4BpjkjinR1NNAy9p1a0Zm2wID KgnhWuBOaGLyTykZ88eqlfzVUQ== X-Google-Smtp-Source: ABdhPJxjnSu+yLHWWJfiy7xRvCiUUgHTAGNwM2UhSXChmSRbPFQ4p7gsIG3bTSR63P416rAUVvCDEw== X-Received: by 2002:aa7:9707:: with SMTP id a7mr6021587pfg.257.1599176051457; Thu, 03 Sep 2020 16:34:11 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id my8sm3390805pjb.11.2020.09.03.16.34.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Sep 2020 16:34:10 -0700 (PDT) Date: Thu, 3 Sep 2020 16:34:09 -0700 From: Kees Cook To: Sami Tolvanen Subject: Re: [PATCH v2 00/28] Add support for Clang LTO Message-ID: <202009031557.4A233A17F1@keescook> References: <20200624203200.78870-1-samitolvanen@google.com> <20200903203053.3411268-1-samitolvanen@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200903203053.3411268-1-samitolvanen@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200903_193413_852138_5E27C861 X-CRM114-Status: GOOD ( 22.68 ) 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: linux-arch@vger.kernel.org, x86@kernel.org, "Paul E. McKenney" , kernel-hardening@lists.openwall.com, Peter Zijlstra , Greg Kroah-Hartman , Masahiro Yamada , linux-kbuild@vger.kernel.org, Nick Desaulniers , linux-kernel@vger.kernel.org, Steven Rostedt , clang-built-linux@googlegroups.com, linux-pci@vger.kernel.org, Will Deacon , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Sep 03, 2020 at 01:30:25PM -0700, Sami Tolvanen wrote: > This patch series adds support for building x86_64 and arm64 kernels > with Clang's Link Time Optimization (LTO). Tested-by: Kees Cook FWIW, this gives me a happy booting x86 kernel: # cat /proc/version Linux version 5.9.0-rc3+ (kees@amarok) (clang version 12.0.0 (https://github.com/llvm/llvm-project.git db1ec04963cce70f2593e58cecac55f2e6accf52), LLD 12.0.0 (https://github.com/llvm/llvm-project.git db1ec04963cce70f2593e58cecac55f2e6accf52)) #1 SMP Thu Sep 3 15:54:14 PDT 2020 # zgrep 'LTO[_=]' /proc/config.gz CONFIG_LTO=y CONFIG_ARCH_SUPPORTS_LTO_CLANG=y CONFIG_ARCH_SUPPORTS_THINLTO=y CONFIG_THINLTO=y # CONFIG_LTO_NONE is not set CONFIG_LTO_CLANG=y I'd like to find a way to get this series landing sanely. It has dependencies on fixes/features in a few trees, and it looks like it's been difficult to keep forward momentum on LTO while trying to simultaneously chase changes in those trees, especially since it means no one care carry LTO in -next without shared branches. To that end, I'd like to find a way forward where Sami doesn't have to keep carrying a couple dozen patches. :) The fixes/features outside of, or partially overlapping, Masahiro's kbuild tree appear to be: [PATCH v2 01/28] x86/boot/compressed: Disable relocation relaxation [PATCH v2 02/28] x86/asm: Replace __force_order with memory clobber [PATCH v2 03/28] lib/string.c: implement stpcpy [PATCH v2 04/28] RAS/CEC: Fix cec_init() prototype [PATCH v2 05/28] objtool: Add a pass for generating __mcount_loc [PATCH v2 06/28] objtool: Don't autodetect vmlinux.o [PATCH v2 07/28] kbuild: add support for objtool mcount [PATCH v2 08/28] x86, build: use objtool mcount [PATCH v2 17/28] PCI: Fix PREL32 relocations for LTO [PATCH v2 20/28] efi/libstub: disable LTO [PATCH v2 21/28] drivers/misc/lkdtm: disable LTO for rodata.o [PATCH v2 22/28] arm64: export CC_USING_PATCHABLE_FUNCTION_ENTRY [PATCH v2 23/28] arm64: vdso: disable LTO [PATCH v2 24/28] KVM: arm64: disable LTO for the nVHE directory [PATCH v2 25/28] arm64: allow LTO_CLANG and THINLTO to be selected [PATCH v2 26/28] x86, vdso: disable LTO only for vDSO [PATCH v2 27/28] x86, relocs: Ignore L4_PAGE_OFFSET relocations [PATCH v2 28/28] x86, build: allow LTO_CLANG and THINLTO to be selected The distinctly kbuild patches are: [PATCH v2 09/28] kbuild: add support for Clang LTO [PATCH v2 10/28] kbuild: lto: fix module versioning [PATCH v2 11/28] kbuild: lto: postpone objtool [PATCH v2 12/28] kbuild: lto: limit inlining [PATCH v2 13/28] kbuild: lto: merge module sections [PATCH v2 14/28] kbuild: lto: remove duplicate dependencies from .mod files [PATCH v2 15/28] init: lto: ensure initcall ordering [PATCH v2 16/28] init: lto: fix PREL32 relocations [PATCH v2 18/28] modpost: lto: strip .lto from module names [PATCH v2 19/28] scripts/mod: disable LTO for empty.c Patch 3 is in -mm and I expect it will land in the next rc (I hope, since it's needed universally for Clang builds). Patch 4 is living in -tip, to appear shortly in -next, AFAICT? I would expect 1 and 2 to appear in -tip soon, but I'm not sure? For patches 5, 6, 7, and 8 I would expect them to normally go via -tip's objtool tree, but getting an Ack would let them land elsewhere. Patch 17 I'd expect to normally go via Bjorn's tree, but he's given an Ack so it can live elsewhere without surprises. :) Patches 19, 20, 21, 23, 24, 26 are all simple "just disable LTO" patches. This leaves 9-16 and 18. Patches 10, 12, 14, 16, and 18 seem mostly "mechanical" in nature, leaving the bulk of the review on patches 9, 11, 13, and 15. Masahiro, given the spread of dependent patches between 2 (or more?) -tip branches and -mm, how do you want to proceed? I wonder if it might be possible to create a shared branch to avoid merge headaches, and I (or -tip folks, or you) could carry patches 1-8 there so patches 9 and later could have a common base? Thanks! -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel