From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <will@kernel.org>
Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75])
 by sourceware.org (Postfix) with ESMTPS id 23C523858D28
 for <libc-alpha@sourceware.org>; Fri, 25 Feb 2022 15:54:35 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 23C523858D28
Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by ams.source.kernel.org (Postfix) with ESMTPS id 0807CB8326F;
 Fri, 25 Feb 2022 15:54:34 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 053A5C340E7;
 Fri, 25 Feb 2022 15:54:30 +0000 (UTC)
Date: Fri, 25 Feb 2022 15:54:27 +0000
From: Will Deacon <will@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
 Szabolcs Nagy <szabolcs.nagy@arm.com>,
 Jeremy Linton <jeremy.linton@arm.com>, "H . J . Lu" <hjl.tools@gmail.com>,
 Yu-cheng Yu <yu-cheng.yu@intel.com>, linux-arch@vger.kernel.org,
 linux-arm-kernel@lists.infradead.org, libc-alpha@sourceware.org
Subject: Re: [PATCH v8 0/4] arm64: Enable BTI for the executable as well as
 the interpreter
Message-ID: <20220225155426.GB20310@willie-the-truck>
References: <20220124150704.2559523-1-broonie@kernel.org>
 <20220215183456.GB9026@willie-the-truck> <Ygz9YX3jBY0MpepU@arm.com>
 <20220225135350.GA19698@willie-the-truck>
 <Yhjxr3+U2qd6b3yK@sirena.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Yhjxr3+U2qd6b3yK@sirena.org.uk>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH,
 DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS,
 TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
X-BeenThere: libc-alpha@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Feb 2022 15:54:36 -0000

On Fri, Feb 25, 2022 at 03:11:43PM +0000, Mark Brown wrote:
> On Fri, Feb 25, 2022 at 01:53:51PM +0000, Will Deacon wrote:
> 
> > I still think this new behaviour should be opt-in, so adding a sysctl for
> > that would be my preference if we proceed with this approach.
> 
> I'm happy to have a sysctl but I'd rather it be opt out rather than opt
> in since it seems better to default to enabling the security feature
> when there is a strong expectation that it would seem better to enable
> it by default sine it's not expected to be disruptive and the sysctl is
> more of a "what if there's a problem" thing.

I think new behaviour has to be opt-in, so that if somebody takes a new
kernel then we can guarantee it's not going to break them. Systemd can
enable this unconditionally if it wants to.

Will