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=-8.8 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 AE5F1C07548 for ; Thu, 10 Sep 2020 18:20:28 +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 2F156206A2 for ; Thu, 10 Sep 2020 18:20:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="r8yG4+IC"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="HLvuaRMW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2F156206A2 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=Zf/DnNfZeZH9X6dpbGJ+A6rc5Y6JK9/6yS8ybNFX5nI=; b=r8yG4+ICoprYcZCl3+3lxeddI C/pGY1dgdmx10FOxw3FjA8SA0Wf/fCKiWIL1gSA1InBq9zrnQE5XTa6rWsDNfPiufFlgD6uRkuerH bm977/ZEpG0/b4BUWZe919UybrYQzTBxy3De5pKcOWfpyFfPbRYyx2e40aLkvh9GXMYYQs0AwcQha eDYU+bqV3lMJ4IUSnwjA6b8K+7GCzjPp+PBt9vtxejXgvR3B0zkkz1fw27qP0YiG2Yp4RntCH+EoI TR06HnBsrD8xzHmaCM0tpXYpCAqWnjSvvN5iIVRS7fX3pe+9CPS9PVJu0Gtfpn9kGmdrW6F1qQcaf /RvDOPopQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kGRA3-0000ie-Vu; Thu, 10 Sep 2020 18:19:08 +0000 Received: from mail-pf1-x444.google.com ([2607:f8b0:4864:20::444]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kGRA0-0000er-Tt for linux-arm-kernel@lists.infradead.org; Thu, 10 Sep 2020 18:19:05 +0000 Received: by mail-pf1-x444.google.com with SMTP id o20so5087054pfp.11 for ; Thu, 10 Sep 2020 11:18:53 -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=NNmcHwO+Iwg+rMeH3STh9feD6/hRsrC6t3t7wQ2j07g=; b=HLvuaRMWnIdqkY/j252Zk2tw3F2MY+FcibjdL/KozWLivJNfEdTrKZ7CqbgRS7PlOp JYDi+SPDHVcl/yQBRgsBfinBkUhTC2Vg4LOpBjFc6XUoK73NwgnL9x33VlwMsXmy4U// L1KOhxbAqZ23ZfVN8lGVbKftKzpOrRTb+F6EQ= 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=NNmcHwO+Iwg+rMeH3STh9feD6/hRsrC6t3t7wQ2j07g=; b=KvrejN2KaxYbg8l+l3ajhH9KSZVY+yutLwDt5JlmrRsjVJVTv9J0cAfuLho7y1YqpW EmemlsISy9muBl+AroBSInXGL8ogaNy0WDZBc3iCWL/JRnrQzHU9twJMrvg9r5X/dQC3 eyEoq2UlmY4c4uJ4td1djvcXvNgXXIgOGWovy2BEyItJSMG6mGHFEkHpJNlER2U1KlIo qOzMvYB5WTMiUXti62GvQNKmwXC3ExYMmpnosmk4kZexf1Dg39334AgeR3c4zmGFXGuH V5dC8CwnZ6aXr9kutXq9BdEK/2pOsI+h+AJznXE43ZL2pNvYZsJpgS43j7/0JcRqk5Ny k2qA== X-Gm-Message-State: AOAM530Vq2iWwujM+6dWO1D3ikk/TABNNfcJUOfr0OinVx3M8Mul+6Ak VRmxENNr+wyj07KpE0/WCZhL3g== X-Google-Smtp-Source: ABdhPJw/4pL1OYUwp6z4yw3Dzx5FlBwoM08u2lDH1WyZ3QTjZmpweja7YeY9sCB7pjDSgbG18rK2lA== X-Received: by 2002:a63:6cc4:: with SMTP id h187mr5452054pgc.129.1599761932269; Thu, 10 Sep 2020 11:18:52 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id k3sm6784065pfp.41.2020.09.10.11.18.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2020 11:18:51 -0700 (PDT) Date: Thu, 10 Sep 2020 11:18:50 -0700 From: Kees Cook To: Masahiro Yamada Subject: Re: [PATCH v2 00/28] Add support for Clang LTO Message-ID: <202009101057.1CCEB434@keescook> References: <20200624203200.78870-1-samitolvanen@google.com> <20200903203053.3411268-1-samitolvanen@google.com> <20200908234643.GF1060586@google.com> 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-20200910_141904_981299_F3D399A5 X-CRM114-Status: GOOD ( 31.89 ) 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 , X86 ML , "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 , Sami Tolvanen , linux-pci@vger.kernel.org, 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 Thu, Sep 10, 2020 at 10:18:05AM +0900, Masahiro Yamada wrote: > On Wed, Sep 9, 2020 at 8:46 AM Sami Tolvanen wrote: > > > > On Sun, Sep 06, 2020 at 09:24:38AM +0900, Masahiro Yamada wrote: > > > On Fri, Sep 4, 2020 at 5:30 AM Sami Tolvanen wrote: > > > > > > > > This patch series adds support for building x86_64 and arm64 kernels > > > > with Clang's Link Time Optimization (LTO). > > > [...] > > > One more thing, could you teach me > > > how Clang LTO optimizes the code against > > > relocatable objects? > > > > > > When I learned Clang LTO first, I read this document: > > > https://llvm.org/docs/LinkTimeOptimization.html > > > > > > It is easy to confirm the final executable > > > does not contain foo2, foo3... > > > > > > In contrast to userspace programs, > > > kernel modules are basically relocatable objects. > > > > > > Does Clang drop unused symbols from relocatable objects? > > > If so, how? > > > > I don't think the compiler can legally drop global symbols from > > relocatable objects, but it can rename and possibly even drop static > > functions. > > Compilers can drop static functions without LTO. > Rather, it is a compiler warning > (-Wunused-function), so the code should be cleaned up. Right -- I think you're both saying the same thing. Unused static functions can be dropped (modulo a warning) in both regular and LTO builds. > At first, I thought the motivation of LTO > was to remove unused global symbols, and > to perform further optimization. One of LTO's benefits is the performance optimizations, but that's not the driving motivation for it here. The performance optimizations are possible because LTO provides the compiler with a view of the entire built-in portion of the kernel (i.e. not shared objects). That "visible all at once" state is the central concern because CFI (Control Flow Integrity, the driving motivation for this series) needs it in the same way that the performance optimization passes need it. i.e. to gain CFI coverage, LTO is required. Since LTO is a distinct first step independent of CFI, it was split out to be upstreamed while fixes for CFI continued to land independently[1]. Once LTO is landed, CFI comes next. > In contrast, this patch set produces a bigger kernel > because LTO cannot remove any unused symbol. > > So, I do not understand what the benefit is. > > Is inlining beneficial? > I am not sure. This is just a side-effect of LTO. As Sami mentions, it's entirely tunable, and that tuning was chosen based on measurements made for the kernel being built with LTO[2]. > As a whole, I still do not understand > the motivation of this patch set. It is a prerequisite for CFI, and CFI has been protecting *mumble*billion Android device kernels against code-reuse attacks for the last 2ish years[3]. I want this available for the entire Linux ecosystem, not just Android; it is a strong security flaw mitigation technique. I hope that helps explain it! -Kees [1] for example, these are some: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=Control+Flow+Integrity [2] https://lore.kernel.org/lkml/20200624203200.78870-1-samitolvanen@google.com/T/#m6b576c3af79bdacada10f21651a2b02d33a4e32e [3] https://android-developers.googleblog.com/2018/10/control-flow-integrity-in-android-kernel.html -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel