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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 551EBC636ED for ; Wed, 28 Aug 2024 17:33:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E44DB6B0089; Wed, 28 Aug 2024 13:33:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DF5516B008A; Wed, 28 Aug 2024 13:33:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CE3906B008C; Wed, 28 Aug 2024 13:33:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B19616B0089 for ; Wed, 28 Aug 2024 13:33:01 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 6901C1A061D for ; Wed, 28 Aug 2024 17:33:01 +0000 (UTC) X-FDA: 82502349762.12.DF43202 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf11.hostedemail.com (Postfix) with ESMTP id A99814002B for ; Wed, 28 Aug 2024 17:32:59 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="O/xcOhor"; spf=pass (imf11.hostedemail.com: domain of broonie@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=broonie@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724866310; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4MDDdzSEhRjEbEa2n9fIYxr42mIY+eyZfSj6+j+Bu0s=; b=Pz62TENhooO0e+Oz2/FDTCXeKFe99IGVS0DQQx9bzWSrMK9MDaasqRiNYaHQJNklFyVci7 /JayG5lzh94QNYdDBQHOu8PjifI/mZeXd0j67yT04zA0sgLk+1HrghPvZfBED9txp3S5vG Zu2gmnJa+RpHWyY0D0pwHgatHffqsNE= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="O/xcOhor"; spf=pass (imf11.hostedemail.com: domain of broonie@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=broonie@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724866310; a=rsa-sha256; cv=none; b=NMPxpq24lJYkURxdGql5Giek1V+Ekqkp6SdFV6N2WjaVy3y/dej6pLg+W594F8e2YeCabY X+nMuuPcNA3FJ9nkQZe91756EfLzrk84DjMZQibNvblVIF7+5RjZhKnwod5cFZRjqSr6+P mQ6Fw7ILi79x4DKJSp4WvytHF3Xlys8= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id CD370A42763; Wed, 28 Aug 2024 17:32:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 71927C4CEC0; Wed, 28 Aug 2024 17:32:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724866378; bh=4MDDdzSEhRjEbEa2n9fIYxr42mIY+eyZfSj6+j+Bu0s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=O/xcOhorFRSv2vHmRagMWmGxh+ScNnb9p5YrzG9/pAmQfUsEg399/CaTU0Z06a3Kd 25gBR9x3tRKON/9TVqn3X9yWKKyvoaXPglSuRX8H/AEzCQfOfamSFXFrUflPvWSiAU m2RTlwhEQm6GYG4Uu3jWFaCtKcYLtQjATOV2MkQy03IMy9y2Bez9OmpxvhprGtMcQG PjRlInV3Bc/JK1THjQVmMuPnn6fu1rOqZ3+sGnnl2KRptQU5L4iIPf6dlZynx0jL9x 730E1RPdEdJUvwP5kiHq7t30Mte5uQ7x3NQJjn8eIqgssRzUyqSg0jXamQWsy9Pz/C BWKufAwkMrGMg== Date: Wed, 28 Aug 2024 18:32:48 +0100 From: Mark Brown To: Catalin Marinas Cc: Will Deacon , Jonathan Corbet , Andrew Morton , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Arnd Bergmann , Oleg Nesterov , Eric Biederman , Shuah Khan , "Rick P. Edgecombe" , Deepak Gupta , Ard Biesheuvel , Szabolcs Nagy , Kees Cook , "H.J. Lu" , Paul Walmsley , Palmer Dabbelt , Albert Ou , Florian Weimer , Christian Brauner , Thiago Jung Bauermann , Ross Burton , Yury Khrustalev , Wilco Dijkstra , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: Re: [PATCH v11 25/39] arm64/signal: Expose GCS state in signal frames Message-ID: <4de41478-3bc8-4cb4-a557-3e9402afe858@sirena.org.uk> References: <20240822-arm64-gcs-v11-0-41b81947ecb5@kernel.org> <20240822-arm64-gcs-v11-25-41b81947ecb5@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qwAebp9So100JWhv" Content-Disposition: inline In-Reply-To: X-Cookie: You are number 6! Who is number one? X-Stat-Signature: znm41wf7obiefp7w1t9y1k7uqh9hzhk4 X-Rspam-User: X-Rspamd-Queue-Id: A99814002B X-Rspamd-Server: rspam02 X-HE-Tag: 1724866379-648231 X-HE-Meta: U2FsdGVkX1/79Eu8PZsLSnmQ1GnwNsLKr3lwlQ4N62/zumYpNLWJ8cyW+j0DcUkA+1EW8Tgcx6KOiVGxl0XHVyiNuFT4H8DeRhzXdscOQ3/2AxOjk6Kf39egx2w27Gmaz5yJm2eo4vUciALK1FVU4zRRYSXu00mgRhqJa6dqMf7AzvPcrZTRlFTllecbHhj317QWoD4Fle9EdAMWPHiNQP5u8gHd+libd0HLsL93KQqzgyKhHTNcs5c3b/3q8HMTu2Fn0jm7Gbjou0GSqDk+lb3ULBvWrsksmdWjzDWa1PpyT9gu3GGNTjRsmdYh7XyQkTv6l9ryBjp9sCvYKdbLRPC10EN1GV+UVMYZlc6DeAeRXijYXPGfkTmqRFCBua2y77Fnw7973cA0GzrVFAO5OztA73h7FiZYTBglSeDvq49I3F8WSN2oHRvjPavjeFuWmchLwfWreU50vnXvNNhBqRBefUo8mVFpM9Wql05kMpDDHuDWQkx/uoqtf020Nz01KAas6cIYZuJ8yvANhE2Q+tonmqEuwRzU2hG1Jxe0/ARAzL06itb4ggMhmFaGXrQLlQB/SCG5SiQHs/BDKNmbctvaliGdPBw1qYVv15EctSCucO5f2Cc9GXl5DVVrw/s4Eco67bN8HfpqjYDtQgrpdoLfWpJqTzK6ARAiGFAkLI3NYUeZGIQh5K8vGAkXvCqxlSnM2E1NGwpmEm1PUup+5unAWjlEqJUjj0P5xL5mf7rZqsS3ADVG53/p2mChhFppYb5qnbkdU/XMVhC1F3USaC5KbNLfH7Ze2NqLdZdsak4m23ZfyBfGxCL5rL3LMXZSUxsDgznnqrrZHZ8QBZwclVnFTioTBmFwJOvRIbTZom83dDQqokxoOUOyKvdIY5zWzwy3d+tasLFxvsoa3h+O4DLHIWDz31Ea/BFe/VkiJgWHsTlYSqXxgASR4Ult1XhgKaGGP5IQVChfx9AQlrc cOesBIYM loQ4UTO3ipySGxeCWYIzyh9xJywoB6R0fClBL8w6Ai/1k3fFVx/QFEgTrWvRCJPp9e4iOxIhr8vwypVOJDfbV2koq5UojkKx8ALyAqIratySpOwxLp7Gp/E/Rh8NvXwv2wSqOtwvpR5LiD+8f8fcfE8e/b5B7cdSpaIsTy0+dt1Qvgxz83OWBbGsnY5/Rba38UpL/QIekObBRg3k17yeYUNSaLf4bFb0SKToPSYEx5toEXE2MkOu3crQtcoWPphkuns8XuX5CzsyrcTNb4JpR3x9uVKpHaD75TOUPoHxdiDBzYB1gAIjQMhlEryrqFO9QSNbRarxvx7sj3SHQHLkNsu0TtRxlMhet9q5X/sduOfMqjixcpKIL65duZdzQLlNhCs1V X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --qwAebp9So100JWhv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Aug 26, 2024 at 01:00:09PM +0300, Catalin Marinas wrote: > On Fri, Aug 23, 2024 at 11:01:13PM +0100, Mark Brown wrote: > > On Fri, Aug 23, 2024 at 04:59:11PM +0100, Catalin Marinas wrote: > gcs_preserve_current_state() only a context switch thing. Would it work > if we don't touch the thread structure at all in the signal code? We > wouldn't deliver a signal in the middle of the switch_to() code. So any > value we write in thread struct would be overridden at the next switch. I think so, yes. > If GCS is disabled for a guest, we save the GCSPR_EL0 with the cap size s/guest/task/ I guess? > subtracted but there's no cap written. In restore_gcs_context() it > doesn't look like we add the cap size back when writing GCSPR_EL0. If > GCS is enabled, we do consume the cap and add 8 but otherwise it looks > that we keep decreasing GCSPR_EL0. I think we should always subtract the > cap size if GCS is enabled. This could could do with some refactoring as > I find it hard to follow (not sure exactly how, maybe just comments will > do). I've changed this so we instead only add the frame for the token if GCS is enabled and updated the comment, that way we don't modify GCSPR_EL0 in cases where GCS is not enabled. > I'd also keep a single write to GCSPR_EL0 on the return path but I'm ok > with two if we need to cope with GCS being disabled but the GCSPR_EL0 > still being saved/restored. I think the handling for the various options in the second case mean that it's clearer and simpler to write once when we restore the frame and once when we consume the token. > Another aspect for gcs_restore_signal(), I think it makes more sense for > the cap to be consumed _after_ restoring the sigcontext since this has > the actual gcspr_el0 where we stored the cap and represents the original > stack. If we'll get an alternative shadow stack, current GCSPR_EL0 on > sigreturn points to that alternative shadow stack rather than the > original one. That's what confused me when reviewing the patch and I > thought the cap goes to the top of the signal stack. I've moved gcs_restore_signal() before the altstack restore which I think is what you're looking for here? --qwAebp9So100JWhv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmbPXz8ACgkQJNaLcl1U h9AINwgAghxTu8PB4VcQHkYwz1H/qDleYcPMAHplNpZgcLpx59wTJgBZ5QfIwDnV v12mJKsZJ3gfnHdZipZjp7EKhKGELQUTGRLICZqBr9S/8SfK3cXC3z6gQEXLxu3W Z122sDonqb/vfykIYhrtWeP12Rgm1n7KRplfJrXGx+xfZD2pQRdydES4L5RWtbZU coJqFBLlGHRFqsnIUQni4PFl1UCQRVitFHHS4nL+Fs/lGj+rkjM69mkCQjmAHR1d /Wivj6fyHPPQj8UCXiCXkk+/KcM64IZqgoTzIdYH+khbjTKKaBC0s06fnqJqU2n1 d06XGwawJkM0HfQlIcf0XRaB8a7aew== =V6Zo -----END PGP SIGNATURE----- --qwAebp9So100JWhv--