Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp934085pxb; Tue, 14 Sep 2021 11:55:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy6GkTf7d+kh7HLn9CEeE06ylt1itIklKsngNfmmDlWtBiVyCd7bXeNEABbytqA6IDAe8Kf X-Received: by 2002:a05:6512:3405:: with SMTP id i5mr13798322lfr.165.1631645754653; Tue, 14 Sep 2021 11:55:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631645754; cv=none; d=google.com; s=arc-20160816; b=viwQ7TgDJmwT78VoNClzg2sZf5hz3xhsS7kRAUCrEcqZddUQXBwuxiG4E9TdHOL9mi N17r2u4J8Dh2TCQVPWMtsl3BYcSpoRioYU9otBAwMJIS8fBgnFjMKRrCAAjQCTwNfHA0 o4kuge2AqZZfIc3d+Q6BgXkK9yc6VMEL8xwHuiRCyvTI2R0+xVWMFul7aQHzTPIZ90by gdKOQQNVB7XROcmaDZiQAMmNGp8JXOvaHK+brNKyBh25xM+XdvPxUaC/aAPwzFn484Eu wvuXbzZiHetwcFFHbBjXTLWA+j37bfG1FklHx29zny5LncSQ08xecHHYehr9oDSVZn74 b9dQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=UaHzCeqz3d/GqpsnFBtK63j5q/ArTL6SIw+4YS9rlLw=; b=LVlFFVWBfu7b85ClR4Ntgtm4vYk+BjmVyt5ofCdFDW4m1o0xXa9eALOG1zTYIXVit0 aALmPBZCRHsqaX1rUpj4r/51Kew6YEkXrKqMQo/Gqciwg3/EkXByi37TvNT+ghUjFfqV atgDB70YMaxjkxOBfbPOQ5OVcsU77HRqqR2hi2HujH49hFHACzI9P+L5X5AFXAUhu6D+ Pt8rhYhDvpKAIrD/NroFe8UvT8Mj5yp/vW6kGVQE+6TFxCiu9Lsy6MJAEluXJC7GUKt6 9x8gwrwkgCc/JPMS5ux7WvTHkqHSIoZQF7p1C4upQq74jNWjSXXONODanNPKSsAgq1ny X5pg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="J/saYQyn"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z6si9912138lfq.420.2021.09.14.11.55.26; Tue, 14 Sep 2021 11:55:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="J/saYQyn"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230332AbhINSzK (ORCPT + 99 others); Tue, 14 Sep 2021 14:55:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44906 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230012AbhINSzJ (ORCPT ); Tue, 14 Sep 2021 14:55:09 -0400 Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EBCBFC061762 for ; Tue, 14 Sep 2021 11:53:51 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id r3so542203ljc.4 for ; Tue, 14 Sep 2021 11:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UaHzCeqz3d/GqpsnFBtK63j5q/ArTL6SIw+4YS9rlLw=; b=J/saYQynIM2X/4guXTj6phyk0pk9kPNeyMN1MMrYWugRxKF5v46ckYr01b8y2ZH48C 0cAm0LfXAw+b09/e44x7gSrBb129qhRALOFIEBrajU/Uurfb+8IS5aCYGVPJW4CVHEXf ng9hed14b/lorCRVBegOw/78skcLggZCds+mIIXoXEveY550QpOrE9P1p1aq/yP8PYYH jKlbSMVrXSyQ1wp9TGBckUJ84ipH1jOLCHitARG6VvyQ+GgpGjoJyMWJVyIb9XSeihYA lPisIrdoBxBzftvoXwYFWXCs8DTNuF1v+SDxtSOAOhEF+D1/EHRslzlXiEECap8/CGP4 4eMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UaHzCeqz3d/GqpsnFBtK63j5q/ArTL6SIw+4YS9rlLw=; b=CR0K0um+z0suaH8jPATNi7AKtzTqgaxvqe0G4Qu30ClrkfKHkCpB435VK47pgHDWar bk7kERVv1O+QfByolR9N8XJrp58vu86XK27tOzW13lRJcpBhXBQZUPxtNjDNwEew1oXL U7SJclCvk8yDMRxAPtM09fYzUftkLSEvSs3SkBz/cYwGM6pBiqH50uccqy+pHV9A4PmV k2gXewszJL/O5lTrgOQBYmCkx13WtTfXlthfryC9SNSpWyz4HbdfSh3iR2Nnmt5HbKu9 PzBOcysJ2Zc/WZKTonSFt6sz5s7mZaizWdCQGGate+m56Nz5/N4wFbo4GYUHk780ZuIb 9zkQ== X-Gm-Message-State: AOAM533FK4WfZAVltiUH3KDnidS2Tv1RGFoyg/SAwht1f3efg/ZfC3yS +DmVBq17naBm8taxNgMgI3M8r/dv7gXpBJGarb1B5V6n6i7aLQ== X-Received: by 2002:a2e:b551:: with SMTP id a17mr16552074ljn.128.1631645630128; Tue, 14 Sep 2021 11:53:50 -0700 (PDT) MIME-Version: 1.0 References: <20210914102837.6172-1-will@kernel.org> <01f572ab-bea2-f246-2f77-2f119056db84@kernel.org> <202109140958.11DCC6B6@keescook> In-Reply-To: <202109140958.11DCC6B6@keescook> From: Nick Desaulniers Date: Tue, 14 Sep 2021 11:53:38 -0700 Message-ID: Subject: Re: [PATCH] hardening: Default to INIT_STACK_ALL_ZERO if CC_HAS_AUTO_VAR_INIT_ZERO To: Kees Cook Cc: Nathan Chancellor , Will Deacon , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, "Gustavo A . R . Silva" , Greg Kroah-Hartman Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org `On Tue, Sep 14, 2021 at 10:21 AM Kees Cook wrote: > > On Tue, Sep 14, 2021 at 08:58:12AM -0700, Nathan Chancellor wrote: > > On 9/14/2021 3:28 AM, Will Deacon wrote: > > > CC_HAS_AUTO_VAR_INIT_ZERO requires a supported set of compiler options > > > distinct from those needed by CC_HAS_AUTO_VAR_INIT_PATTERN, Fix up > > > the Kconfig dependency for INIT_STACK_ALL_ZERO to test for the former > > > instead of the latter, as these are the options passed by the top-level > > > Makefile. > > > > > > Cc: Kees Cook > > > Cc: Nathan Chancellor > > > Cc: Nick Desaulniers > > > Cc: Gustavo A. R. Silva > > > Cc: Greg Kroah-Hartman > > > Fixes: dcb7c0b9461c ("hardening: Clarify Kconfig text for auto-var-init") > > > Signed-off-by: Will Deacon > > > > Reviewed-by: Nathan Chancellor > > > > One comment below. > > > > > --- > > > > > > I just noticed this while reading the code and I suspect it doesn't really > > > matter in practice. > > > > > > security/Kconfig.hardening | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening > > > index 90cbaff86e13..341e2fdcba94 100644 > > > --- a/security/Kconfig.hardening > > > +++ b/security/Kconfig.hardening > > > @@ -29,7 +29,7 @@ choice > > > prompt "Initialize kernel stack variables at function entry" > > > default GCC_PLUGIN_STRUCTLEAK_BYREF_ALL if COMPILE_TEST && GCC_PLUGINS > > > default INIT_STACK_ALL_PATTERN if COMPILE_TEST && CC_HAS_AUTO_VAR_INIT_PATTERN > > > - default INIT_STACK_ALL_ZERO if CC_HAS_AUTO_VAR_INIT_PATTERN > > > + default INIT_STACK_ALL_ZERO if CC_HAS_AUTO_VAR_INIT_ZERO > > > default INIT_STACK_NONE > > > help > > > This option enables initialization of stack variables at > > > > > > > While I think this change is correct in and of itself, > > CONFIG_INIT_STACK_ALL_ZERO is broken with GCC 12.x, as > > CONFIG_CC_HAS_AUTO_VAR_INIT_ZERO won't be set even though GCC now supports > > -ftrivial-auto-var-init=zero because GCC does not implement the > > -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang > > flag for obvious reasons ;) the cc-option call probably needs to be > > adjusted. > > GCC silently ignores the -enable flag, so things actually work correctly > as-is. So then would that mean that CC_HAS_AUTO_VAR_INIT_ZERO_WITH_ENABLE evaluates to true then, in your patch below? Rather than create 2 new kconfigs with 1 new invocation of the compiler via cc-option, how about just adding an `ifdef CONFIG_CC_IS_CLANG` guard around adding the obnoxious flag to `KBUILD_CFLAGS` in the top level Makefile? > But, yes, it makes the command line long and doesn't make sense. > How about we do this instead: > > diff --git a/Makefile b/Makefile > index 34a0afc3a8eb..34439deac939 100644 > --- a/Makefile > +++ b/Makefile > @@ -831,12 +831,11 @@ endif > > # Initialize all stack variables with a zero value. > ifdef CONFIG_INIT_STACK_ALL_ZERO > -# Future support for zero initialization is still being debated, see > -# https://bugs.llvm.org/show_bug.cgi?id=45497. These flags are subject to being > -# renamed or dropped. > KBUILD_CFLAGS += -ftrivial-auto-var-init=zero > +ifdef CONFIG_CC_HAS_AUTO_VAR_INIT_ZERO_WITH_ENABLE > KBUILD_CFLAGS += -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang > endif > +endif > > # While VLAs have been removed, GCC produces unreachable stack probes > # for the randomize_kstack_offset feature. Disable it for all compilers. > diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening > index 90cbaff86e13..beea81df3081 100644 > --- a/security/Kconfig.hardening > +++ b/security/Kconfig.hardening > @@ -22,14 +22,22 @@ menu "Memory initialization" > config CC_HAS_AUTO_VAR_INIT_PATTERN > def_bool $(cc-option,-ftrivial-auto-var-init=pattern) > > +config CC_HAS_AUTO_VAR_INIT_ZERO_WITHOUT_ENABLE > + def_bool $(cc-option,-ftrivial-auto-var-init=zero) > + > +config CC_HAS_AUTO_VAR_INIT_ZERO_WITH_ENABLE > + # https://bugs.llvm.org/show_bug.cgi?id=45497 > + def_bool !CC_HAS_AUTO_VAR_INIT_ZERO_WITHOUT_ENABLE && \ > + $(cc-option,-ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang) > + > config CC_HAS_AUTO_VAR_INIT_ZERO > - def_bool $(cc-option,-ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang) > + def_bool CC_HAS_AUTO_VAR_INIT_ZERO_WITHOUT_ENABLE || CC_HAS_AUTO_VAR_INIT_ZERO_WITH_ENABLE > > choice > prompt "Initialize kernel stack variables at function entry" > default GCC_PLUGIN_STRUCTLEAK_BYREF_ALL if COMPILE_TEST && GCC_PLUGINS > default INIT_STACK_ALL_PATTERN if COMPILE_TEST && CC_HAS_AUTO_VAR_INIT_PATTERN > - default INIT_STACK_ALL_ZERO if CC_HAS_AUTO_VAR_INIT_PATTERN > + default INIT_STACK_ALL_ZERO if CC_HAS_AUTO_VAR_INIT_ZERO > default INIT_STACK_NONE > help > This option enables initialization of stack variables at > > > > -- > Kees Cook -- Thanks, ~Nick Desaulniers