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 EB6ADC3DA42 for ; Wed, 10 Jul 2024 18:27:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 23D4F6B0088; Wed, 10 Jul 2024 14:27:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1C5136B008A; Wed, 10 Jul 2024 14:27:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 049A26B008C; Wed, 10 Jul 2024 14:27:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D3AA16B0088 for ; Wed, 10 Jul 2024 14:27:12 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 883711601DE for ; Wed, 10 Jul 2024 18:27:12 +0000 (UTC) X-FDA: 82324675104.29.9FFA001 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf19.hostedemail.com (Postfix) with ESMTP id 2F8AC1A0023 for ; Wed, 10 Jul 2024 18:27:09 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=kBignoqF; spf=pass (imf19.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=1720636015; 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=zjRdEplzFBaxIN8wnM5hiY3Ha+Y/O5TStGoRFYx63jU=; b=ZXVFWc5Ju9C0g5VcEG2mdqn9rDYaHbdLw3QiAMiNfQoyFmBl2+3jHP+q2HHUBAS5QYZTST sQX1RkyYHxEdkB8GWWvL9HHkz6UieEulf/ag66bsEz2Fa18/h3DZ0Dg7sUttznSfhTt7NM HKbQOtH0gLWMgdadhFS57UnCAD3JX/o= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=kBignoqF; spf=pass (imf19.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=1720636015; a=rsa-sha256; cv=none; b=a6E82mQEpEkBnZU9kolgbBZraz9/iKL24dDeHnlI0Obv/g2eFGNvdjaYgPHQWhkNNZjT3W VtlBygRhjhjgJFnBTr3fsCnNB1WjQXCWoqeqYvaF8kbar0Kq0xkIbG0fMGAtaJZtFLxvJu OZPGxGcUMQ183YwSrUgIWMfJfP49RbQ= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 70090CE13BB; Wed, 10 Jul 2024 18:27:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C5056C32781; Wed, 10 Jul 2024 18:27:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1720636023; bh=eRrtqZRqKI+Vs713ksZJJnhpC7362rwfU+pQUCdgXy0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kBignoqFgMiQnAofIwr6TpBgYH9jPjzRaSC842ug8+rx6x5ll0CjTdOuNwKz+XNaU NDvkrwV2QNWMtc2QwoU1ijOz5da9rUzzZ4Zm4X9y1ohMBoG7CVKn0v8dUDWTmbo5kp qCrq3abaj3XVJlXugg7JTU4S4r1FduVMcT4Z37pYvXrQ+HC5Pfyh6axADebI74bLMd mL+FCPzGJMJSDDh/UgJFPTRSJhQcGB2O3dEluBrE8THwZhBROKgdbzxw1XeKE8fCoR WqmFYL3/Bn0OvLOJQI+kNsc03yBZkhbSjm+4JlasoCc+ZLBwTbq5WG/vpdgUXOB+/4 KqrO9fqPgf3Gw== Date: Wed, 10 Jul 2024 19:27:00 +0100 From: Mark Brown To: Florian Weimer 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 , 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, "Schimpe, Christina" , "Pandey, Sunil K" Subject: Re: [PATCH v9 05/39] arm64/gcs: Document the ABI for Guarded Control Stacks Message-ID: References: <20240625-arm64-gcs-v9-0-0f634469b8f0@kernel.org> <20240625-arm64-gcs-v9-5-0f634469b8f0@kernel.org> <87a5iph6u2.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GNMZNZkOBV+voqRu" Content-Disposition: inline In-Reply-To: <87a5iph6u2.fsf@oldenburg.str.redhat.com> X-Cookie: Your love life will be... interesting. X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 2F8AC1A0023 X-Stat-Signature: 6d6pq6cpha6d9zbtcdqjzdooisauf1rx X-HE-Tag: 1720636029-901526 X-HE-Meta: U2FsdGVkX19VlkeQTqlWMzgUeuYiW0xg6GihWaC+6eJZvGypkRpB6rc4qPTpEuEnsJQ3I6apzAhcUCYJZAUk4jMjsftwha++b3nfn/ks3SxpJ8+8QUBVKz2o2MxwQz9q6S/0eLU0/FgTV4cWpRYtNQcy+9aIM/3syM/JpBKtLDYq8bwyTGc4KrFswCcZq2HwXPwHZFr7FdKXiNHu9KH8FkdYxcu46Upn3oh+EcRzZzrhl3I8q5F+eG6EmvRr460jnrzDYbVbvy62Rj//YpPdvTEuxyddMJbBQUmNWNl2mL0Ph2gTj8ULKUEoWLWoWmz6Jvn5S9sqfapNocI8OYdFQ6PNes3Z8fGde0iTutTy40FW3AMtBEE1gxIP95+c5pWP2pRoDA1ijZvMQUsz5NEf5ClDwZbWJ6hb3PRmE2fatDR+3a/xbJ1LUZV+VW2rc6tX3sHIEjkDAU62j6enJiL7TFGHJilMCItIu0Da6cldb4g7WHPGnLHYtpcBEF8UbUY7uwU9lD+dDzO1aMtOiuI71Cv9LLgV56G8d6Ia4imNBPkCSOsHeQ955gFnBszn0BvUmbFLWqu6Z1DgD8zaFnbJ7a/MXUaKji5SUjciFfAHBRUlkSnvu0U4AKl25KVY7SQycqWlzVLI2bXvm7onJWVK3pZyp0Yut9DMFQUR/2vJfu99GNT/kP+XRyIpCzxW2AqP+z+qu4o15xH2pjU6IUDwWDD+Lm3kNh3YxifSR3JyGYrNabvmPFBnt277Bap3nPSId2UxAhREGccAQJnry4bdKAE0hF62G+2FtPsnWLPUIf4GNEoMBhkp/Lkzkex1XXyUQ3+y7OCalQ6xcISsZ/Hx9NasDpJUKiSGaE2pTNTQdk5v/KMGzG50u9krTX8/cAbib3mY1T8BKbZHXWEy1KhSAO2pt1AOQMCLGY4P5jdJIivYiPZEvTBSNeHXlz3eWcIHQ179K4Fh9GlhC7BIWuU QjCnZ/Pi 9nq5XWWFl9PdDdtdkSkg76ehmBEezQKu23IfSjlPcsjZlHnmA5v5evgIPhDK+SBGVyi8fYRgMEu/ZVmKssX+OJhpxBr2eb0FHGKIYEHLE2747yu+qjenaqJVrrILIGIsFg2MwxLtZ2p28/pVKXJ0e9TPdwQ2yzhGF6ejfGjeyzM+wkMMgoTbmnkQPspNLcFDK+IYhIw2MHS/ST0P12ef7q326HP5GLgPhbFNfRM/Xif2XkmA9kINsWHYZ7Qp5QkKnR0twwgFUCvW2lhzFKjWTObylEktk9mvENw/varCv249jq1JuDiP+iFKeTQLHt+H2BhXfFWGYJZRC2x+6LIsZ2DVwGp6Hc7M2nXx6 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: --GNMZNZkOBV+voqRu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jul 10, 2024 at 12:36:21PM +0200, Florian Weimer wrote: > * Mark Brown: > > +* When GCS is enabled for the interrupted thread a signal handling specific > > + GCS cap token will be written to the GCS, this is an architectural GCS cap > > + token with bit 63 set and the token type (bits 0..11) all clear. The > > + GCSPR_EL0 reported in the signal frame will point to this cap token. > How does this marker interfere with Top Byte Ignore (TBI; I hope I got > the name right)? The specification currently does not say that only > addresses pushed to the shadow stack with the top byte cleared, which > potentially makes the markup ambiguous. On x86-64, the same issue may Indeed... Given that we use the address on the GCS as part of the token on first pass I think we could get away with just using the address and not setting the top bit, we'd have an invalid cap pointing into a GCS page which shouldn't otherwise be on the GCS. I'll give that some more thought. > exist with LAM. I have not tested yet what happens there. On AArch64 > and RISC-V, it may be more natural to use the LSB instead of the LSB for > the mark bit because of its instruction alignment. The LSB is already taken by the architecture on aarch64, the bottom bits of the value are used for the token type field with no values/bits reserved for software use. > We also have a gap on x86-64 for backtrace generation because the > interrupted instruction address does not end up on the shadow stack. > This address is potentially quite interesting for backtrace generation. > I assume it's currently missing because the kernel does not resume > execution using a regular return instruction. It would be really useful > if it could be pushed to the shadow stack, or recoverable from the > shadow stack in some other way (e.g., the address of the signal context > could be pushed instead). That would need some form of marker as well. Right, we'd have to manually consume any extra address we put on the GCS. I'm not seeing any gagetisation issues with writing an extra value there that isn't a valid stack cap at the minute but I'll need to think it through properly - don't know if anyone else has thoughts here? --GNMZNZkOBV+voqRu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmaO0nMACgkQJNaLcl1U h9CYNwf9FL92M924ZTMgdzdOGnvfj92Q8ImGFAmDoUP3IjVPivJTPYhDuY+GaQaY hojzU0+/ygci8GNBa3kaJGdT2kzo4J6aMfzV8Lw5OFhjfZvg98gQbw+HeRVou0BB trtAQLx/+CWEYHy1qXMPQ3jRHuINOT80L4T321NSPyd7rlSksPpZU/NqHmUI9iW9 MpODGOLfCOg2W3CrQMA8AT1F09NeC4fBr+XRq1f3PwskzNRz/DR89M1amdCG7bky oOk/WAsSGY8RWuY7/GurREwf7vUc1akIFax3lqDscpCbSuZ89FcFfs6YEAUqgq86 qV5kGewLUdqaGwutNJRSCAV+QkJXjw== =dJd9 -----END PGP SIGNATURE----- --GNMZNZkOBV+voqRu--