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 D2E33C433EF for ; Mon, 6 Dec 2021 18:07:39 +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=4DZ1D5j177m9zWYUgaxiI4F/y0U62cOLzKGaCaIhmRk=; b=RHznVg5U+o4m0oDuy2KRXVSG/V UjmL7zqjjbD4ZdYQ7qs14xr9hOsTh4t3Kxr+jgfajtRTjdbdkkmkJjdm3k4Yza5918OB0jdEpzkwz Nlj+F8bY9H0buVjST+pypC8wFcsjzDLaMCNt5uT5kTQFpzSzadhtDj09nCQwr6mvvW1fjMCf/yPg+ 3KDbzp//4qx8jfIPH7z/Z60G6HVkvja0+Ts3zeeV6TQo8Wg2reSFN8WRcpUnaPkLsHlnv8WXlmdJg zFv8vfSVM3mYD/FN01JvRa7Qgq7C6ZJrLLNoN5i9wrG/uWQm4D+gG3RPat+ylc5N32p/EB7P0bJbF BKFiEDpw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1muIND-005DBa-NA; Mon, 06 Dec 2021 18:06:00 +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 1muIN6-005D9A-IJ for linux-arm-kernel@lists.infradead.org; Mon, 06 Dec 2021 18:05:54 +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 BE398CE169F; Mon, 6 Dec 2021 18:05:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BA5D3C341C1; Mon, 6 Dec 2021 18:05:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1638813949; bh=IchoEV8ymu5MBO/ZItFzdpDNo2z2n7FzTUMM0eeIk3w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=O1TNqFthu8e448AvwMBm/oHl1F+d6XVoxWwha+epQW4gUt2OHh2wjG6QOo6WWK+/r Vf/BsY2QP5iyzxh07SZ++6JV0Bz7JYHheKesJNKGze3wBLEsXGB95y+bzRTBezo2NW qX181pH80x3kdZrfsB98OFulgAin//k/OVUkwJKRe8NCp40PmMqMNWKWz2uR8Mk/1y KL60Kmh4WvC8kbCdTqeqCVJF7Sw7Nni88PF0XCprJm+P3gEVLc3+73aFO/gEZ8l42L aFJeegYVI3sRFRcdhAAe43WBfzA7vIohl5MEVbuQ6+szofi8xSQ/ZRAMi5rfqRx1FX E/cybxtw29nUQ== Date: Mon, 6 Dec 2021 18:05:44 +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_100553_026526_53EB1702 X-CRM114-Status: GOOD ( 27.87 ) 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="===============2229766712863286079==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============2229766712863286079== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6wzEWpLy7UHtxK1i" Content-Disposition: inline --6wzEWpLy7UHtxK1i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 06, 2021 at 04:30:41PM +0000, Mark Rutland wrote: > Looking around, there are other places that open-code `hint 34`, e.g. > arch/arm64/crypto/aes-modes.S. Those are unconditional, so we should prob= ably > figure out whether we want those to be conditional (or if we're happy to = make > the other cases similarly unconditional). It seems to *just* be aes-modes.S AFAICT and that does rely on having the BTIs actually emitted (well, and kselftest but that can't use any kernel internal helpers so it's not relevant here). > I'd argue we should probably place BTIs in assembly unconditionally, on t= he > assumption that they shouldn't have an measureable performance impact in > practice (as we're already assuming that when CONFIG_ARM64_BTI_KERNEL is > selected anyhow). Thoughts? I'm not sure what you mean here? We do already add BTIs unconditionally to SYM_FUNC when BTI is enabled for the kernel, it's only SYM_CODE where we don't. For SYM_CODE it seems unwise to add the BTIs since there's things like the vectors that get covered and it's not really idiomatic for SYM_CODE's whole "I know exactly what I'm doing" thing. I also don't know if we end up with SYM_CODEs for anything particularly space constrained other than the vectors, I can't think of anything. 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 implements 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. > Regardless, I reckon we should probably define a `bti` macro centrally in > arch/arm64/include/asm/assembler.h, something like: > That seems to do the right thing: 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. > Can we simplify the ifdeffery so that we only conditionally define BTI_C,= and > unconditionally define the sites using it? That way if there's a problem = with > any of the users that will consistently show up in testing, regardless of > whether CONFIG_ARM64_BTI_KERNEL is selected. >=20 > e.g. we can make this: >=20 > | #ifdef CONFIG_ARM64_BTI_KERNEL > | #define BTI_C hint #34 ; > | #else > | #define BTI_C=09 > | #endif Should work. --6wzEWpLy7UHtxK1i Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmGuUPgACgkQJNaLcl1U h9CkvQf/VYjJhM994H7V2O1Txp/499cf1922zJkDNkTgjdMpXX7D0gsKE6k0O19U d64XeIYzmaRL08En4LEyyzDRQhg7+GHH8im0/7abj25fzKHIxCmjkx0v6T2PsJ0j Xoq8VhjSLl9cwKfS6w/YuR/BAvnV+RPFo9zwQSNTLEpxRHtnf3WWjO3fX+77LWB5 7iUNPWu9/du/WOpOZQHeQw6C4CeLRRnxiQYtDhyNX6aom1M1VA3L79cz16RN5lox 89hT2E+edakxsI8U8nxd3Yns5lDbyv9YKw4exMoS0SsI3Iepzkv41V1yzWjtRnOA S40FggQ8sLrUp/URNTxojm79Ngzf2Q== =Oy84 -----END PGP SIGNATURE----- --6wzEWpLy7UHtxK1i-- --===============2229766712863286079== 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 --===============2229766712863286079==--