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=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 24944C64E7C for ; Wed, 2 Dec 2020 18:55:56 +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 A30672173E for ; Wed, 2 Dec 2020 18:55:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A30672173E 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=P3oWGc34SujhK/UQ1yChbNwPqhPRxgLB/dH6SuRHB2U=; b=rM7pf4ZDF1MTg4OsmNSdJ6I6U GW0BG2RuV/LAj51LmfnkQeZAqJOwX7r3KovR0UnGt1FGl38oPuvM5MwcGmdcfmznCtziLfWSxUxl5 9nFSLs93bbQLjYPoFdhfaALZmHUZ02YefQtCBBPUakqAqxNCvDT1lgDZZoQQB374+Wn2WVxthVN8k xafxrhYCzPo5itNB4GlEHhzLajAljBhV1Ko4MSNA0FISH1Ab06VjLmU7SKsyprqVFyiPTdKG+BqSG DerVusjN+P7JvKF2PrWVNUNk38UpW+y5wh/k66gJZRochjfWuPYugw738wmZZd6+mRbVsIbqDPwW1 9pkUbWVeQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kkXGx-0006IP-2P; Wed, 02 Dec 2020 18:54:39 +0000 Received: from mail-pl1-x641.google.com ([2607:f8b0:4864:20::641]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kkXGZ-00069C-RP for linux-arm-kernel@lists.infradead.org; Wed, 02 Dec 2020 18:54:33 +0000 Received: by mail-pl1-x641.google.com with SMTP id x15so1641214pll.2 for ; Wed, 02 Dec 2020 10:54:13 -0800 (PST) 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=b0+bgE4T7KwQd0o1rvb3kJK3SimQlgs22CmXZhVLCKg=; b=QROM0g6hLow6GZ7V4UDEra8QnuXAyNQydFYd8tPdysSPgI/afRnHzMYcjQDJs2MPB5 4FHG2f99kdxwjDywXRoVakgANSW9WNU9vfancQ5ol/JYM0ZhkZcqC6lujqrqP2v+MmPf J2cFUpIzUbXWhObQk0kvkRk5lgSkJmlLPa0ho= 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=b0+bgE4T7KwQd0o1rvb3kJK3SimQlgs22CmXZhVLCKg=; b=REUwb7TM8FOjPdE05YrgbrIEW1Ke6JMcSkaP0G+OHNHY+mwNaZPjonC7PYgwpZcm1R Tr+FlwjlMyEd2qH4WH2pv6DxayJnioGPnIgcc+ebNX1L1QE5yYp4amqRseschCmNMVN/ T6cZ2lCt7J4m+Xb2NkWvZETVBnjgLlCptUJUnoroGr/Y8HepMqsbcYVPrVTDznj8Tcmr x10z0lmoYMH6xgw7Tqw0ofOBhhV1es2fyVXP5tzUoZeN21vEj1nm+CyviFb9XFe1dHJF DbmD5uo02wPIyzYDgR4C8Wp8is5VBhTvAPNbSmh5bz87Y5TNI3LZIt+km0JGO7AsVXA3 2ldQ== X-Gm-Message-State: AOAM533HF3wMdYmkIqbG9crcqPtCxJo6fDJ/2pu+1SbNFsIseZeVG4cl p/BR1p9fB7lAbL86tROJxbMeKA== X-Google-Smtp-Source: ABdhPJyXCkgyp1gKYUQlD8LDgoMFvwqHsxFF5beeKPp+ajldaiiTSe5K5j/sXDeIE9XjSAHHC0sgfQ== X-Received: by 2002:a17:902:b207:b029:d8:fdf3:af30 with SMTP id t7-20020a170902b207b02900d8fdf3af30mr3838177plr.31.1606935251732; Wed, 02 Dec 2020 10:54:11 -0800 (PST) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id z17sm346946pjn.46.2020.12.02.10.54.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Dec 2020 10:54:10 -0800 (PST) Date: Wed, 2 Dec 2020 10:54:09 -0800 From: Kees Cook To: Masahiro Yamada Subject: Re: [PATCH v7 00/17] Add support for Clang LTO Message-ID: <202012021042.A76E8F06@keescook> References: <20201118220731.925424-1-samitolvanen@google.com> <20201130120130.GF24563@willie-the-truck> <202012010929.3788AF5@keescook> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201202_135416_041330_858B6120 X-CRM114-Status: GOOD ( 35.93 ) 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 , "Paul E. McKenney" , Kernel Hardening , Peter Zijlstra , Greg Kroah-Hartman , Linux Kbuild mailing list , Nick Desaulniers , Linux Kernel Mailing List , Steven Rostedt , clang-built-linux , linux-pci@vger.kernel.org, Sami Tolvanen , Josh Poimboeuf , Will Deacon , linux-arm-kernel 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 Wed, Dec 02, 2020 at 11:42:21AM +0900, Masahiro Yamada wrote: > On Wed, Dec 2, 2020 at 2:31 AM Kees Cook wrote: > > > > On Mon, Nov 30, 2020 at 12:01:31PM +0000, Will Deacon wrote: > > > Hi Sami, > > > > > > On Wed, Nov 18, 2020 at 02:07:14PM -0800, Sami Tolvanen wrote: > > > > This patch series adds support for building the kernel with Clang's > > > > Link Time Optimization (LTO). In addition to performance, the primary > > > > motivation for LTO is to allow Clang's Control-Flow Integrity (CFI) to > > > > be used in the kernel. Google has shipped millions of Pixel devices > > > > running three major kernel versions with LTO+CFI since 2018. > > > > > > > > Most of the patches are build system changes for handling LLVM bitcode, > > > > which Clang produces with LTO instead of ELF object files, postponing > > > > ELF processing until a later stage, and ensuring initcall ordering. > > > > > > > > Note that v7 brings back arm64 support as Will has now staged the > > > > prerequisite memory ordering patches [1], and drops x86_64 while we work > > > > on fixing the remaining objtool warnings [2]. > > > > > > Sounds like you're going to post a v8, but that's the plan for merging > > > that? The arm64 parts look pretty good to me now. > > > > I haven't seen Masahiro comment on this in a while, so given the review > > history and its use (for years now) in Android, I will carry v8 (assuming > > all is fine with it) it in -next unless there are objections. > > > What I dislike about this implementation is > it cannot drop any unreachable function/data. > (and it is completely different from GCC LTO) This seems to be an orthogonal concern: the kernel doesn't have GCC LTO support either (though much of Sami's work is required for GCC LTO too). > This is not real LTO. I don't know what you're defining as "real LTO", but this is, very much, Link Time Optimization: the compiler has access to the entire code at once, and it is therefore in a position to perform many manipulations to the code. As Sami mentioned, perhaps you're thinking specifically of dead code elimination? That's a specific optimization. > [thread[1] merging] > This help document is misleading. > People who read the document would misunderstand how great this feature would. > > This should be added in the commit log and Kconfig help: > > In contrast to the example in the documentation, Clang LTO > for the kernel cannot remove any unreachable function or data. > In fact, this results in even bigger vmlinux and modules. Which LTO passes are happening, how optimization are being performed, etc, are endlessly tunable, but we can't work on that tuning without the infrastructure to perform an LTO build in the first place. We need to land the support, and go from there. As written, it works very well for arm64 (which is what v8 targets specifically) and the results have been running on millions of Android phones for years now. If further tuning needs to happen for other architectures, config combinations, etc, those can and will be developed. (For example, x86 is around the corner, once some false positive warnings from objtool get hammered out, etc.) I still want this in -next so we can build on it and improve it -- it has been stuck in limbo for too long. -Kees [1] https://lore.kernel.org/kernel-hardening/CAK7LNASMh1KysAB4+gU7_iuTW+5GT2_yMDevwpLwx0iqjxwmWw@mail.gmail.com/ -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel