From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by sourceware.org (Postfix) with ESMTPS id 50A0C3858410 for ; Thu, 6 Jan 2022 19:07:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 50A0C3858410 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 E0C3BB8234F; Thu, 6 Jan 2022 19:07:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E2E8C36AEB; Thu, 6 Jan 2022 19:07:49 +0000 (UTC) Date: Thu, 6 Jan 2022 19:07:46 +0000 From: Mark Brown To: Catalin Marinas Cc: Jeremy Linton , Szabolcs Nagy , Will Deacon , "H . J . Lu" , Yu-cheng Yu , linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, libc-alpha@sourceware.org, Mark Rutland Subject: Re: [PATCH v7 0/4] arm64: Enable BTI for the executable as well as the interpreter Message-ID: References: <20211115152714.3205552-1-broonie@kernel.org> <20211209111048.GM3294453@arm.com> <101d8e84-7429-bbf1-0271-5436eca0eea2@arm.com> <8550afd2-268d-a25f-88fd-0dd0b184ca23@arm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="l2QZb2k3HSz7cwiU" Content-Disposition: inline In-Reply-To: X-Cookie: I think we're in trouble. X-Spam-Status: No, score=-5.3 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2022 19:07:55 -0000 --l2QZb2k3HSz7cwiU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jan 06, 2022 at 06:13:37PM +0000, Catalin Marinas wrote: > On Thu, Jan 06, 2022 at 10:09:35AM -0600, Jeremy Linton wrote: > > This should only change the behavior for for binaries which conform to the > > new ABI containing the BTI note. So outside of the tiny window of things > > built with BTI, but run on !BTI hardware or older kernel+glibc, this > > shouldn't be a problem. (Unless i'm missing something) Put another way, now > > is the time to make a change, before there is a legacy BTI ecosystem we have > > to deal with. > The concern is that the loader may decide in the future to not enable > (or turn off) BTI for some reason (e.g. mixed libraries, old glibc on > BTI hardware). If we force BTI on the main executable, we'd take this > option away. Note also that it's not only glibc here, there are other > loaders. Neither of those examples should be concerns - BTI is per page so you can mix BTI and non-BTI freely in a process (as will happen now for the case where the dynamic loader is built for BTI but the main executable is not, and the dynamic loader should do if there's a mix of BTI and non-BTI libraries). The main case where there might be a change would be the case where there's individual excutables with incorrect BTI annotations which are run under this seccomp MWDE, then the dynamic loader might have support for disabling BTI based on some configuration but wouldn't be able to due to the MWDE. Note also that we're only taking the option of disabiling BTI away in the case where there's something like this seccomp filter disabling permission changes. --l2QZb2k3HSz7cwiU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmHXPgEACgkQJNaLcl1U h9BnZwf8DjoXbcOhQVC2ociT04WJ+fR7GYQLHGkX92IGTyo2qFUd99hIzIuHiYbp zFWG/wqqtnuzBEQGK/MMsTNzWqLnpXtlF2NxFEdJTtFl6bYnTkShYr71UHnDlW6H 9vbA46Jb9G+EyO7DYnLlCva5VwZ7GwRrOaD3DdllLpe99BQevwM9g+lHj3wRuOXK gLO+TdaUxe8kdAMqcDy1xHMF/j2XnYLkwVr4Jq+R5iotZ5LmwtSYcd/MYv2x+o2E nNAZJJT6yIF9VCVEWVRKK2WgxaI5HVtLPtbi/XGEh942rG8pPC+GAKFV2KDDy4pX 4eg1OMGWz8lJm5TW2ZFmBkiCGT5zYw== =Lecu -----END PGP SIGNATURE----- --l2QZb2k3HSz7cwiU--