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=-3.8 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 2B191C56202 for ; Fri, 20 Nov 2020 20:43:46 +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 AC3C92223F for ; Fri, 20 Nov 2020 20:43:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="NeM7Sx97"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="GpFB8JoF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AC3C92223F 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=gPVfFneusO0xCDVs2JEzOv7p78JyQQR9vQr9JiJAoNA=; b=NeM7Sx97Xa9QDbHPlMBeWIgMw dlizoDai+ltlICl/r15L9TSlAhsy+iCrFDt0YS8V6Eev/q5DIBxJn3AMxXF09QV0L7e6k2bfuQxwp rJh9A36CRQPCktMX/1ThawLGy/5yzKu749F3ven9LHh4+/IAM5oFyPaDGXqJn2mHpQdGfsFjyQUtb Ox831629VSsQzX6DxSEAgaQvS5qDUaAvAtBwsgmX70YiR1d80pTjQks0oVzgWl4f5+p/WApnNCGKd PPJKcmrO0oFXuzbsFI/9xtb4L/apHF6mTQKZfhE1lhquc7ZvDIZ1XDbYgisgsHq6tQVtlvWEWKwFz C/m4QH9ig==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kgDFY-0004ms-K6; Fri, 20 Nov 2020 20:43:20 +0000 Received: from mail-pf1-x443.google.com ([2607:f8b0:4864:20::443]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kgDFW-0004lm-BO for linux-arm-kernel@lists.infradead.org; Fri, 20 Nov 2020 20:43:19 +0000 Received: by mail-pf1-x443.google.com with SMTP id w6so9026672pfu.1 for ; Fri, 20 Nov 2020 12:43:18 -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=i55oAU3/0ChRWnSy8Vy2lsf5/3oQQZ1SpwWH7R5fDAQ=; b=GpFB8JoFYlzs5IPt1A4zHefiujfDAb4Aupd2Gt8XWPGlHwTgyLSPZ69lnmpG8AcDUI P5TQWbT45S+7ZLN8NYpqb8spc1x7xM2RTsvR4yoBcsZ8FoV3W56Xp36fdQTbZm5G+EPS 8sdwQfqqqLt9BxwKajipmRGH3q24bpLwIUoOI= 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=i55oAU3/0ChRWnSy8Vy2lsf5/3oQQZ1SpwWH7R5fDAQ=; b=ZP2Nza15iflpTM6o1zSmVQUhdSel/V5dak0i9U5EtdPcBYsnDLNMCBtYZVzTttvK3J MnEbREV1/+LOZdbfxvVKJQc3A1WZG0su9P02lGDkgRz0mL520cekvd+z6mZIDxuDj/j9 bfe0OsWHeJNYSCNRESZfW6ZsDKoVl0GqUrj6xRx6W0RSYMbnjbB5VAEhcosx8bGTeorZ aEXHrXZCOA/AVvfjAdznOVNAxamHZL7RFZV1dTR0VTVhMwGmAkRXX6OoZYSEiCk7jG/Q zqOxh/Y2HN3i/Ebr9WBUJPSW5OnFHrHIut14tp4ZhJsvB1qMPvaAIhh9cpL8ZCr77qc9 a2CQ== X-Gm-Message-State: AOAM530C69OTY65zCk8jtvxxA8nooXxptUzNqDSTioYdC0WrxqEM+wC5 xlmDpZhMwByIroCyhuGLXlG7gQ== X-Google-Smtp-Source: ABdhPJwImKJNbu1EQwiGGAUktKiLdCpi1F8qQGza+VZgx7A7t3fyRz/FVTV1hNGkrOLQAws/XjLW2g== X-Received: by 2002:a17:90b:e08:: with SMTP id ge8mr12659157pjb.29.1605904996598; Fri, 20 Nov 2020 12:43:16 -0800 (PST) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id l133sm4882417pfd.112.2020.11.20.12.43.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Nov 2020 12:43:15 -0800 (PST) Date: Fri, 20 Nov 2020 12:43:14 -0800 From: Kees Cook To: Nathan Chancellor Subject: Re: [PATCH v7 02/17] kbuild: add support for Clang LTO Message-ID: <202011201241.B159562D7@keescook> References: <20201118220731.925424-1-samitolvanen@google.com> <20201118220731.925424-3-samitolvanen@google.com> <202011201144.3F2BB70C@keescook> <20201120202935.GA1220359@ubuntu-m3-large-x86> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201120202935.GA1220359@ubuntu-m3-large-x86> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201120_154318_431576_3CBAA55E X-CRM114-Status: GOOD ( 21.06 ) 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 , Masahiro Yamada , Linux Kbuild mailing list , Nick Desaulniers , LKML , Steven Rostedt , clang-built-linux , linux-pci@vger.kernel.org, Sami Tolvanen , Josh Poimboeuf , Will Deacon , Linux ARM 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 Fri, Nov 20, 2020 at 01:29:35PM -0700, Nathan Chancellor wrote: > On Fri, Nov 20, 2020 at 11:47:21AM -0800, Kees Cook wrote: > > On Fri, Nov 20, 2020 at 08:23:11AM -0800, Sami Tolvanen wrote: > > > Changing the ThinLTO config to a choice and moving it after the main > > > LTO config sounds like a good idea to me. I'll see if I can change > > > this in v8. Thanks! > > > > Originally, I thought this might be a bit ugly once GCC LTO is added, > > but this could be just a choice like we're done for the stack > > initialization. Something like an "LTO" choice of NONE, CLANG_FULL, > > CLANG_THIN, and in the future GCC, etc. > > Having two separate choices might be a little bit cleaner though? One > for the compiler (LTO_CLANG versus LTO_GCC) and one for the type > (THINLTO versus FULLLTO). The type one could just have a "depends on > CC_IS_CLANG" to ensure it only showed up when needed. Right, that's how the stack init choice works. Kconfigs that aren't supported by the compiler won't be shown. I.e. after Sami's future patch, the only choice for GCC will be CONFIG_LTO_NONE. But building under Clang, it would offer CONFIG_LTO_NONE, CONFIG_LTO_CLANG_FULL, CONFIG_LTO_CLANG_THIN, or something. (and I assume CONFIG_LTO would be def_bool y, depends on !LTO_NONE) -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel