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 8A910C52D6F for ; Wed, 21 Aug 2024 18:28:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E85316B0175; Wed, 21 Aug 2024 14:28:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E5C3F6B017B; Wed, 21 Aug 2024 14:28:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CFD516B017C; Wed, 21 Aug 2024 14:28:11 -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 AFB226B0175 for ; Wed, 21 Aug 2024 14:28:11 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 358D8140157 for ; Wed, 21 Aug 2024 18:28:11 +0000 (UTC) X-FDA: 82477087182.18.C69D7A1 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf20.hostedemail.com (Postfix) with ESMTP id 6F72A1C000C for ; Wed, 21 Aug 2024 18:28:09 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=aTYagprE; spf=pass (imf20.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 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=1724264783; 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=WBFZu11lyX/c2H2Rod7l+lG+dzNjW+RnesdzAXT1be0=; b=PW5xJ6usGGssSITERye/H3qJC7WESiSaYyhu5Fwlm4AW2TUUtrMysW66r12h3sSqDHhinv 3P2Hzz/dG39l4eP1F4p38BnuwKP0520greK80zX0Aaorma9N4xJlM+zRqiHgmoN8JoGmJw UlEU/o1AzccsACGD5HY2P7h/6PTMp5s= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=aTYagprE; spf=pass (imf20.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 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=1724264783; a=rsa-sha256; cv=none; b=hIXydhPVYUoksm9LSlv2StEsM5WNHbOcLD72Hjw0ZVnOmHVhVaDaS9zlQ4IyxpqTkvJ6lS RoEgsYT+X6mlCLiG+4clCyoh2/DsTlXkxnGFLF4GjKF8fnIH8VMSPlFqCMUzcSN4a49+i/ zZ1yW6exFIgOAc3JIp7tdIAMpkB1tEU= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 61D7660FFA; Wed, 21 Aug 2024 18:28:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA21CC32781; Wed, 21 Aug 2024 18:28:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724264888; bh=33baSij/lfUz4rEbu0DhfDZckukmuW2FH61KazHkxLQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aTYagprEzcz2g3EIW4SxspQ7iO18F5DjDWUNZgvbFQBngLuxfa6dpeP9T9dw7WcuL wATPmQQbugIpTAh+yu8sQl3uSAiFbniz7t3a2VnwftqkWda+6Ps2U60RXXCERSDZKk 2G5yackwgc9NzDJc7QB/noWi9xSl7fY6yumKqreAng88x0/HI5LN6dTxOu0JwDYf32 p3tyUuzRIkNq5iNeYht0PNQ+RGraYbbe95MRQSJXxDFqT1bsLDmzRKGdCcZTHGY5YK AJQoS+KuBojRbSang2TOeLaRZyoOISyOl2kL2kBHWHcU8AvSgrttUrgRRyzQGIPGaq KzW+H6ExR6s6Q== Date: Wed, 21 Aug 2024 19:27:53 +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 , 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 v10 25/40] arm64/ptrace: Expose GCS via ptrace and core files Message-ID: <58ee01de-88a6-4d0c-845a-3d5bebc0c55c@sirena.org.uk> References: <20240801-arm64-gcs-v10-0-699e2bd2190b@kernel.org> <20240801-arm64-gcs-v10-25-699e2bd2190b@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XTSIK84UC9+qnNMX" Content-Disposition: inline In-Reply-To: X-Cookie: You are false data. X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 6F72A1C000C X-Stat-Signature: whtx37at4ro667abu8o6dc8ktyud8foh X-Rspam-User: X-HE-Tag: 1724264889-889983 X-HE-Meta: U2FsdGVkX1+JJcGZTJPUXyiIVmLPGlSYTJM9630PD/ziHUiXyLkP5/H3ZQyAbmjMNBrPBEE7ndb89gZWe/NHtn9xmHIFzcEtPJma6B2XHLhLtKUDd51oYkl0kAXKsNFsfaFhyOeV3EkhX9ia2hqU7zgdLnqBHZC6l1N1PTsgdu1uVKbtQw9q5kClozfOFL0ToQ4DMSng9DsrPRznd0hD/YLnBdHSamaiVreB1Yj8LS9yz2VBqAFhpjIElff3aurPsgCxgWRk0jSBZ9WPOcSki9pYKRIpZgE1Gd9w/UUQPkmWmNC4R6fkv/cELMfd6MPG3wRI3xFpjKCkdKVeODuK05rkPAa4xBV3VgRYAM+bgGY9cAMDSHI5Iwv832I2a7fMwayorDJPNFjxt8BdGgCti29xOt2DBSUXbEIuvnIyCHYTgm4UY9iIfcxX1fa1/mAb2tmf62+Od6rUOdKw/xwvG8GH3afDtTBfkv+ffVfU9Fa7U4VzApiav5s+R37h9wWbM77qHy1LlAhc3l7TcOq00buWAktZbGhVfe2WG9SxlqtIcrynK3TpZ4gHlPPSoXXdmBIVnBYwWyIGRf6WSTKkr0ESKpjhQvKd5b51cYWVNkPRl0u4tp4OWghcuEQ6V9RxENKOZoqUIwFXvxCpRh354Zzf19hfcSLCeQQlEUct34ksZzjXa071R1EavtcnVegKNIoXkhuZESiTovEeQPFZ/1WOlDuks6zm432+lBI0dDAqHLsIe4O4KaeaiP4xw1/MLdFsh4dOXUOqbyCKC1p9eQldF7zqZ58Cm+b5bHbK369rR0BPYXRr8N6+i2i385fQUPzyuhuV9VcwDJdqmvaaCFNN4ks/4y7W6Ane0bc2XFJvh1o5Y19YFyqSoGukCeRlqOfhLvpXQQtCgctF7Z4X6Jr5cyNRBmCFxGq85b0fm9NZf1ljd0oQm/58Wjf44z4U1tV++A1cO+8lbpHy5B3 f6WoUUhB x+ZcojTpFc/0yqBK68xq0CPfLuE7eaBC/Rk+i4E12k6u9StpyYWwV6oCKNuWGxcODVVbXcDm63iC/o1XOBVktUMnhCQAsklag29jfM1wsBcsaYxHGKoLeyp5aOSndyD98yVYhc5yBvhvnSA4ncvnhVUlq/v5MTg4rlb3bnGu9Wjc0gPSBzvSAHmM9CNDhzSAFhPQTDjlqCuM8i5xzFXGGtj4dbGWvVIIM6mvyGeq7ycxagF0w6RcQoJR64Z4aJpx8aTddMA9MlGnRRUlCd0nuiU7lbvawDEJDv0hcTG8fxl+huQAbPbAUnndx1HvlLKqHc6dmA3zEYesQ855DJQFRSCYgYrwOcKIsQNRyAXoJUJbEyko= 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: --XTSIK84UC9+qnNMX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Aug 21, 2024 at 06:57:16PM +0100, Catalin Marinas wrote: > On Thu, Aug 01, 2024 at 01:06:52PM +0100, Mark Brown wrote: > > + if (user_gcs.features_enabled & ~PR_SHADOW_STACK_SUPPORTED_STATUS_MASK) > > + return -EINVAL; > > + /* Do not allow enable via ptrace */ > > + if ((user_gcs.features_enabled & PR_SHADOW_STACK_ENABLE) && > > + !(target->thread.gcs_el0_mode & PR_SHADOW_STACK_ENABLE)) > > + return -EBUSY; > > + target->thread.gcs_el0_mode = user_gcs.features_enabled; > > + target->thread.gcs_el0_locked = user_gcs.features_locked; > > + target->thread.gcspr_el0 = user_gcs.gcspr_el0; > As in the previous thread, I thought we need to restore GCSPR_EL0 > unconditionally. My thinking here is that if we return an error code then ideally we shouldn't implement any changes, especially in cases like this one where we're rejecting inputs that are just invalid. That seems like the least surprising outcome and what we should strive for, even if it's too complicated for some cases. It is possible to write GCSPR_EL0 regardless of if GCS is enabled, it's just not possible to write it as part of an otherwise invalid write. The validation is checking for unknown features and enables. With clone3() we could relax the enable check, but I've just pulled that out of the series for the time being. > I don't particularly like that this register becomes some scrap one that > threads can use regardless of GCS. Not sure we have a simple solution. > We could track three states: GCS never enabled, GCS enabled and GCS > disabled after being enabled. It's probably not worth it. Yeah, I did give consideration to that but as you say I think it's probably not worth it - you end up with a state machine which for the most part only gets two of the states exercised. > On ptrace() access to the shadow stack, we rely on the barrier in the > context switch code if stopping a thread. If other threads are running > on other CPUs, it's racy anyway even for normal accesses, so I don't > think we need to do anything more for ptrace. Yes, I don't see any reason to try to do anything special there. --XTSIK84UC9+qnNMX Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmbGMagACgkQJNaLcl1U h9Db9wf/YDOH2BjzBXwu0lqzdwn2i+txsrhK+t+d9GX2VzQ6TRQJVseEw3ZiryNO J1DTR+iMp5FlHiA+dBqzqZs6Fm09BlHVaMuawV056J8O9fcpyhzG+xMMxoPyAika UeVQkZEUvs2eE76O+txWVhVwfLbKWAspcwflXBcFPVd8iT3yQxAgcS4k/h40zC3M h96mx+doBNKP+V9QlLlcLMiSsPS6VVN6PGE36A1uHbJWx03Kg133qsB+hzBPC8DU mJUnsZprHcbNVOYMJa/HMExbUltPGbuN61YzZvRT3mXkX/eykU2RkhITaZ7p8H8m SUu+YRFrKXGRJYWTXtUkcFtUO90vrA== =5j94 -----END PGP SIGNATURE----- --XTSIK84UC9+qnNMX--