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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1A514C433EF for ; Mon, 6 Dec 2021 19:33:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=XD94i+wpcO1nTN7hYZ+RCi/AIAj/Ctdyai97NGixu90=; b=y0FMg1OUwC0K3cKVXfDCVN9WhT 414h6ZMpRJNS1apDb3NYzMzqWTV5tnY1noLahK/C3S6lbZEDWFow3CGzvdU0g4XIK7daeubEd0I5C BLSyO/E5FuA8xuaaw284h+ZvN4QfL6wfrWENuld2pBLtJYgszBuDREg57IZITLsiWNPM/VJ9GEnDq 3hdNBMia6zqkhEzKJVAkMXEZ7P2i44g55S2/ZOS1m6BcivIBkWRDU+LzFYLqwkh+f1ZrCmfThjPkQ prR/ugB8sGRmKtYDHmdHgKZcCT2WciDWkj0KNF6h7aZjPoiYOyrv0DfXN75cze0Ai6YPaTamML25H X+A4CO3Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1muJiP-005VYM-Ek; Mon, 06 Dec 2021 19:31:57 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1muJiM-005VXV-2j for linux-arm-kernel@lists.infradead.org; Mon, 06 Dec 2021 19:31:55 +0000 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 sin.source.kernel.org (Postfix) with ESMTPS id 11BEBCE17A6; Mon, 6 Dec 2021 19:31:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 08D6AC341C2; Mon, 6 Dec 2021 19:31:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1638819108; bh=R7OuGTPy8Dflv/78EQU9zHWhbXnXlT4K0LYSS/mnyPM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Xl7r2SQ1iFXW1ho7HLw3VxmVExY65FLsF0anrznMC/kDF2YrqR1bsqXCvL67OB4kB PCtbDser0nOSgba32C7YWD5sFr1U7qSQDK6kvq8UYqS4MHre4UL+9wR08sP9jKbHFs YCFnb30Dve8LXQJ5BxKBTmFJz0L3P31+QC1W92ET12LiMXa1bOlXU65N/yWAjqmJUc R2xhnYxXuI5aIMvttbcPQWde3GFcwaBIstLdScHn39UeeBShrrtkyw5fzRDbIhqOWJ x08KPYIiQSBok8tv29Q5/9f1P3BYivTTtzgcOhoZVpr3afvYxAGBx2y4UK4y9oU0+A M5vys2C1XTwug== Date: Mon, 6 Dec 2021 19:31:43 +0000 From: Mark Brown To: Mark Rutland Cc: Catalin Marinas , Will Deacon , linux-arm-kernel@lists.infradead.org, Ard Biesheuvel Subject: Re: [PATCH] arm64: asmlinkage: Enable use of BTI_C macro in SYM_CODE Message-ID: References: <20211203130335.84733-1-broonie@kernel.org> MIME-Version: 1.0 In-Reply-To: X-Cookie: You will soon forget this. X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211206_113154_534511_D9171D4E X-CRM114-Status: GOOD ( 36.75 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1094298229099275597==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============1094298229099275597== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JIzcgr37e5fCdUkv" Content-Disposition: inline --JIzcgr37e5fCdUkv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 06, 2021 at 06:38:46PM +0000, Mark Rutland wrote: > On Mon, Dec 06, 2021 at 06:05:44PM +0000, Mark Brown wrote: > > On Mon, Dec 06, 2021 at 04:30:41PM +0000, Mark Rutland wrote: > > If you mean that the macro should unconditionally emit BTI when the > > macro is used then the main reason I didn't do that was for consistency > > with C code - that will only have BTIs added if we're building with BTI > > enabled. There is at least one implementation out there which implemen= ts > > unknown HINTs with a performance overhead compared to NOPs so that is > > one of the reasons why the kernel might be built with BTI disabled. > I appreciate that rationale; I'm saying we should re-evaluate that. =2E.. > If this does actually matter in practice, then I'm happy to make it > conditional, I just think we should err on the side of simplicity otherwi= se. > Especially as we already have on case where we add the instructions > unconditionally, in what is arguably fast-path code! Hrm. I'm not sure I see that as a substantial win TBH - it does make the assembler output more consistent but it's also not what I'd expect to happen if we turn off BTI for the kernel. I guess it's just the usage in the AES code that's making you think of this - all the issues have been missing landing pads in SYM_CODE? =20 I'm not exactly against it, I'm just unclear on the upside which makes me feel like I'm missing something. It feels like this comes from the current conflation of conditionally providing the macro with conditionally using it in sites where it can be omitted. My instinct is more to do something like define your BTI C macro unconditionally but still have a conditional thing like we have currently at least for SYM_FUNC, possibly renamed though. Actually now I think about it we may also want to think about pointer auth for SYM_FUNC, but that's definitely a separate and more substantial thing that needs much more consideration and is out of scope here. > > Yes, even seems to do the right thing without complaint if the assembler > > is configured v8.5 and so understands v8.5. My main worry would be the > > potential confusion caused when people see what looks like it should be > > a v8.5 instruction in code which is supposed to build configured for > > v8.0, it looks wrong to see something that looks like a more modern > > instruction in code that should be buildable with a toolchain that > > doesn't understand it. > Sure, but that's already the case for SB and ESB, so I'm not sure that ma= tters. Oh, ick. I may perhaps be more sensitive to this than most due to working with the FP code which has more hand assembly than average. --JIzcgr37e5fCdUkv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmGuZR4ACgkQJNaLcl1U h9B5CAf/QeYr+CIKTsUcWUuB7OgeGc2nE34HxEsXZW7XjiovSu02yU4O0N4Jmrsm 3YP09rV1AqRYtoTVkPrDvjvPSh+pvZMbUmHDN6IziGEsS4Gr8DqnLM0mnzqJojTL ESZ9O5ZtcUXIuIPVxoN86ry+Erfv9MeLxxpwXPxnZAKf/RT4fsnejE8ZbksqTuoj 0Zo3lu8NhSc6K5p0i8ZlY1vB+AXOWals4qSI7sH2k9ufBi/xEFKEnD4oxDZsr4CM 6lBq1h263cxFk3LgzgRnESSqHjgz/10wArwgfLTS7qGaeiC3HB5Gr3kNyX2zVEk8 wkzcTDbYBreYZa0EHlyEi/5/Pao95w== =P5qy -----END PGP SIGNATURE----- --JIzcgr37e5fCdUkv-- --===============1094298229099275597== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============1094298229099275597==--