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 C25F0C3DA4A for ; Wed, 14 Aug 2024 16:00:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 40B196B007B; Wed, 14 Aug 2024 12:00:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3BABF6B0082; Wed, 14 Aug 2024 12:00:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 283686B0083; Wed, 14 Aug 2024 12:00:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 0A8946B007B for ; Wed, 14 Aug 2024 12:00:44 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id E9FCFA1040 for ; Wed, 14 Aug 2024 16:00:42 +0000 (UTC) X-FDA: 82451313924.19.BB721C0 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf14.hostedemail.com (Postfix) with ESMTP id 0F33810003C for ; Wed, 14 Aug 2024 16:00:38 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=C1Qo0Znc; spf=pass (imf14.hostedemail.com: domain of broonie@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=broonie@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723651227; 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=JkvZZ7OvWA9vMA26TB77C5oo0F0JnioDu/uzQCrOqvA=; b=ekOhd4LdbTWWdINkrznjWb5R3xAtOufL3yzJutP18S+VgDjZ8VKgY4WtK/pp3csdiR36v/ BvsuWFgMj7TUteBAB/HV11e+O4rMzOppbV7W3fvBvvoc4Cx9jW8OSNmPC+dt4DRJy5ml0Y piSeWCA7PKBabMoBatxd1cfNRdgbTP0= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=C1Qo0Znc; spf=pass (imf14.hostedemail.com: domain of broonie@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=broonie@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723651227; a=rsa-sha256; cv=none; b=wrnjS0aExe6D3v4UkKsUj5CVp7rrJ6uyTSta59bFy1wLDelKpJXTN+eTfK9Dzlabaqj73G s8pCuczywxcGVfnOkWEfiiAQBz49W4s1Wjero3AqcDTyG0vHYQcmKSrwrZtDMZPxdWjJwE tEY3cWFftRdwgYlgDL/foqEYH440g04= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 1F44DCE195D; Wed, 14 Aug 2024 16:00:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AAE22C116B1; Wed, 14 Aug 2024 16:00:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1723651233; bh=tJ9y/t0p8CoWT3GLrKdQZ0dSWk0FZ5F+3VCb9/8rtJc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=C1Qo0Zncz+RdR9DeUEI52CB7DQtewBYXVGfRUQ4A1toxpkFsbuQ6aJyDgJz7UfDuH bzxXCMK2CVyRwzj4Fzsp12NcASucmaKle8j/eMgOwWVzR2lvflN7lzCLHhTyQ3ScD3 +3H4j8mCCyM0GSJc3pBhGBO2bXmXG5WzBuDhGy5GyWML6OrUSxKM3fVQt794iZbGN7 zq37MEqlxsQmv9ud3qgMIDnCP26tQt1p0hjVBhliLYp5ui4XBUgvCNn/OsKWmUZrSd Krpj/jmqgiJLPoYpTX6m1uOjpJNj4kjuDK0YvvBuQWHt0Y9IyIEzIa3etR5NZwtbL6 zsq/MP82yJmiw== Date: Wed, 14 Aug 2024 17:00:23 +0100 From: Mark Brown To: Dave Martin Cc: Catalin Marinas , 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 23/40] arm64/signal: Set up and restore the GCS context for signal handlers Message-ID: <08932f6d-01ef-40e8-97d2-08f0d2016191@sirena.org.uk> References: <20240801-arm64-gcs-v10-0-699e2bd2190b@kernel.org> <20240801-arm64-gcs-v10-23-699e2bd2190b@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="d9byunHM6BED1bDk" Content-Disposition: inline In-Reply-To: X-Cookie: The second best policy is dishonesty. X-Rspam-User: X-Stat-Signature: ymfdcj7t4qhicd4x1n9dpnpksaobrag6 X-Rspamd-Queue-Id: 0F33810003C X-Rspamd-Server: rspam11 X-HE-Tag: 1723651238-598913 X-HE-Meta: U2FsdGVkX18/W6angkQDZ5wpP1toRwbUj6POb/YsuadoTY40F7+SAShBlmmGWqq+JAozE9C/zr3b2JWiZyxFkNW3WerdfKgifDr8ItFPO6NTEUCgeyuWP9DWkiEtS14W55ZPrVzEtnIIqFO7mB/WMrLmU5ifIXEGcycXS33jIu0OjiICYveDrOWb8jwW1MAyxVd2RExaGcq9CvsNTCOT5978v83aCTGgeUKtiohUZGgDljX2Z99y3MH/nWvOgFJ6qNcTzBL8WYviANo8NI+ccJjNPZNkwuVX4BDDcEFGlJgJ+Ql8zTQqpPAadTYxuQzzv+mCgJixK/CAct4+wGt1K3Jrx3Yr690T3h2rqHvVOqCHyJ6ZKENWDKSIhZ7WPJDG8ZqPgfc+XaNvqamOSxKdgbiyi4NWNF+P2JFG/IeRgz3czl92Cl5zo9O3qmTMSAE9pQmaSGyUzAufTyfPeUELDrwm+vuD3GY0NtISfWog0veYqHvK2WPO4z6ISpTXVHO0KuKpAGW4XgnKiKhfZFcQjYr/X9r2aX+EepZqmOQKUmd+WDvmKBgFLWzCD+vuSYcNMxzxF6+1fEY525IJOEGfIS5H8jercD3gdh182IVyM9uVk8Wnczqg3TAtEc4by6/jCvEhTCdnrM7CUw2v9/Q+X84yIgBkHv56KxJIn1a9MKKS7vV2y5x14goyAToSkIrvXF4fU78d1B0RMqkHbblnXqBGTOJF/HIwwS6Ja/pDP1yswaWDyBsuyx+k46P72Y0EfmTqMh6N/mMAOi3aEw/g0YyjJFuxo5CCq641ibL8q8M9aSkJ0rPB79+ZntstsIlNytX/wTFB4IZU4JMZHiYgYrGeXe52ey5Lpya1v09AIlwxe2aMiVxim7kOsOg6muZrKkRetKdR9XZ/C9QfcMmNXciODStwY8Ukvx2LC8Yu8mrYbGOuC/5fvFma1Wc1zyWm0SF3fBmfgeSh+EAdmoV Q74PM0lG 933Wm7QPE6J2/OIcM1x6P5nxfMjD4rBlV2hGYDtoyOS2hMBflOtC02vdBRCmaiB33B4bpdCNjIEU1DH0qBCeFd4TbC1jKInBISFf1fndJ1G7J4jvk7gVtvwzJ81EwBT9z/rhoYcBIc0CWa7envb/xH1ADSbeiIs1wbtHqzo7Iua1sk5pqrTYnIPtIvbEiMRox4Uoao3IM3Tqvmd9ENliqmo0qC2jXptdJETuHBPsEAsOlUlRJrRbALUlbYiEDyYYGflDVL6nJj1+yWxia2XrrdBOpGlI5utlsPNFbZQ9Yk7mrE09a/gQhShQoZfF3s7nMjhne0rIJXLBYLx7ch/M8OVsxfXNbX/jU8xgC 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: --d9byunHM6BED1bDk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Aug 14, 2024 at 03:51:42PM +0100, Dave Martin wrote: > On Thu, Aug 01, 2024 at 01:06:50PM +0100, Mark Brown wrote: > > + put_user_gcs((unsigned long)sigtramp, gcspr_el0 - 2, &ret); > > + put_user_gcs(GCS_SIGNAL_CAP(gcspr_el0 - 1), gcspr_el0 - 1, &ret); > > + if (ret != 0) > > + return ret; > What happens if we went wrong here, or if the signal we are delivering > was caused by a GCS overrun or bad GCSPR_EL0 in the first place? > It feels like a program has no way to rescue itself from excessive > recursion in some thread. Is there something equivalent to > sigaltstack()? > Or is the shadow stack always supposed to be big enough to cope with > recursion that exhausts the main stack and alternate signal stack (and > if so, how is this ensured)? There's no sigaltstack() for GCS, this is also the ABI with the existing shadow stack on x86 and should be addressed in a cross architecture fashion. There have been some discussions about providing a shadow alt stack but they've generally been circular and inconclusive, there were a bunch of tradeoffs for corner cases and nobody had a clear sense as to what a good solution should be. It was a bit unclear that actively doing anything was worthwhile. The issues were IIRC around unwinders and disjoint shadow stacks, compatibility with non-shadow stacks and behaviour when we overflow the shadow stack. I think there were also some applications trying to be very clever with alt stacks that needed to be interacted with and complicated everything but I could be misremembering there. Practically speaking since we're only storing return addresses the default GCS should be extremely large so it's unlikely to come up without first encountering and handling issues on the normal stack. Users allocating their own shadow stacks should be careful. This isn't really satisfying but is probably fine in practice, there's certainly not been any pressure yet from the existing x86 deployments (though at present nobody can explicitly select their own shadow stack size, perhaps it'll become more of an issue when the clone3() stuff is in). --d9byunHM6BED1bDk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAma81JcACgkQJNaLcl1U h9DStQf+MHf5MIvFUrZBpQZg07XSllBYTCVHtBIGn5XzIx/KW1GJXKIov1DxWUTX 4/a2ua/8So/yt7XHqWLjBgCUd7U4AsSNKO3kBxUGH1j85SY4YPkZtb+t8AriDoS5 aBVNq2boS8RzipYyeieLa1TUtet845IqOUX6AZ6yMIyWEcqaST5KfdYG0vmy3tKH Rk85zpx0YvxXhmd63f+dAZYPPsOxVaJxVgUGl8/qDJzXEHHsT8nNlkLc4x6s7vja MyVsVWQGYTa7MKQofcxfH+yB1UtWlMV9oxMRWab4Uy7GPaBO05yTKxDukJQUklbt S47T7TUaZvxSLe1aJLMls0FHfdO5uQ== =go3J -----END PGP SIGNATURE----- --d9byunHM6BED1bDk--