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 BFF5EC3DA42 for ; Wed, 17 Jul 2024 15:29:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 528EF6B008C; Wed, 17 Jul 2024 11:29:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D80B6B00A1; Wed, 17 Jul 2024 11:29:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 378D06B00A2; Wed, 17 Jul 2024 11:29:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 18D966B008C for ; Wed, 17 Jul 2024 11:29:27 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B795714187A for ; Wed, 17 Jul 2024 15:29:26 +0000 (UTC) X-FDA: 82349628732.22.336555C Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf15.hostedemail.com (Postfix) with ESMTP id 39102A0031 for ; Wed, 17 Jul 2024 15:29:23 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=r3PIF9no; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf15.hostedemail.com: domain of broonie@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721230120; 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=ukWBWdiCV90bf+K1lUELQn/UyLGZdA/ugOA19ZyBXHk=; b=hICiJ8bBR9fcTmV+G67oHVe2nyb0wiXx1tDAndgHIs5CIhnrhEy02LYdQ/YEwqxJBW1N9j cb6gV5SwpbCg+OWH9Zg2YPdOH5QZKtLfe106z6HxR7UdF3gWIhyrP5uRI1UyIytXkUNUTE u01kv4a40/8nk9jO6R9f8s2z8loTx7s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721230120; a=rsa-sha256; cv=none; b=4p2wRFoZFncmWdxQ3LaXqt8ams25vlI80U4sXInVBlmDnUG6ANucVjP0t/Ce5afC5ylirJ GV4104DYk56Gzz3J4VXnvjIB/W5agSXGJWMZ5dnDJHxPw7lzzBw6f1T+j7L3oTTa/7ezZ2 4JT4F22nDjp0Po+9Xm1yLMMCDT7xJKI= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=r3PIF9no; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf15.hostedemail.com: domain of broonie@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=broonie@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id D3E73CE17E0; Wed, 17 Jul 2024 15:29:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9A4EEC4AF11; Wed, 17 Jul 2024 15:28:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1721230117; bh=ukWBWdiCV90bf+K1lUELQn/UyLGZdA/ugOA19ZyBXHk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=r3PIF9noxw/EmK0iQ64CIvMRoQtkUSZm+1XevS7zxoStKg5JQPXHJlg8IU5RJZpcr kkF2HbTJe+ClHj3+rZQDKaKK2Cy4VcJvwK2A40VhLza++TNBmeFKpxsYozVv1V+RJd BeHJUyzEuN47tHZ6V6NszSlSMSW94Va2/HjvLsAeMB6t5uPrWosA0FKDJ+PlgEaZog 3KzdUg9k+Nx1gMZjK7jl1xM1jAOpM3bo5Qp47w2Q9KaDwUpZns+jwrGfVa+4n+Wi50 DUlk9Lud/2N6I51hkdkPMdV+XmlL1vfq4/oVWxBdhChNqFtoGDJReknBht7B/a4Tbe Y1QWQ/qq+FoyA== Date: Wed, 17 Jul 2024 16:28:27 +0100 From: Mark Brown To: "Edgecombe, Rick P" Cc: "fweimer@redhat.com" , "sroettger@google.com" , "linux-arch@vger.kernel.org" , "ross.burton@arm.com" , "suzuki.poulose@arm.com" , "Szabolcs.Nagy@arm.com" , "linux-fsdevel@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "Schimpe, Christina" , "kvmarm@lists.linux.dev" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "catalin.marinas@arm.com" , "kees@kernel.org" , "oliver.upton@linux.dev" , "palmer@dabbelt.com" , "debug@rivosinc.com" , "aou@eecs.berkeley.edu" , "shuah@kernel.org" , "arnd@arndb.de" , "maz@kernel.org" , "oleg@redhat.com" , "thiago.bauermann@linaro.org" , "Pandey, Sunil K" , "james.morse@arm.com" , "ebiederm@xmission.com" , "brauner@kernel.org" , "will@kernel.org" , "hjl.tools@gmail.com" , "linux-kselftest@vger.kernel.org" , "paul.walmsley@sifive.com" , "ardb@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mm@kvack.org" , "akpm@linux-foundation.org" , "linux-doc@vger.kernel.org" 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> <2fb80876e286b4db8f9ef36bcce04bbf02af0de2.camel@intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="h9KvXQkczWY3GIVF" Content-Disposition: inline In-Reply-To: <2fb80876e286b4db8f9ef36bcce04bbf02af0de2.camel@intel.com> X-Cookie: You should go home. X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 39102A0031 X-Stat-Signature: 8tdjamyxh9sbq5kjafi83uejh9tr9ssd X-Rspam-User: X-HE-Tag: 1721230163-589068 X-HE-Meta: U2FsdGVkX19piKlu5b7NEqgIUkpmCaClwC5tRYlOg2/SIUcn6nY160h0kCSyN+Jt3U57Lva+I3qKsa9U7FC8HoXxEstle/UOoSXdo0NFydkHXGE5bpnsAFkq4mJsI/JO20br+fTNCRUYpw0EcwRFkZKgAmoAywcjmQa1TX/HuqlL7PSd08x8VQQV3RG/P4J0vRIbufSQamzuVU24t6bzIuVzEMcJyWRBL5Oe1z59QGqBSf7PrWPKPxEQvHs/Rck4uVSJJ92xvnDFUO47Jcj9h8SqMzafJQPCe2omUkacTrRRnmmi6YDWjsOkUeuMqxzHhJL3kFqDAdLxcAcm1E7WGcbnmZIUn8hKOInwMpZUav1qm+Jr5wGxNiIuXeZwfw4J1Lev4qJ41wkCTqNxjepVUVJEWvBUdRStlFIjEOGO+GKvMVyq5yP5MWevC3WCor6zr56TMZrkd+Vxrv7j2AOvTsC8W/gYTkU78raGUiWlRYMNJVNHRRw/nLvekbwZzPpC+CW58aCteOwr/8pQ88QJTeRAI7wEOvQp64ozBGJ5ltRqE/Zv59FtX95dKpekLhJjCkRlfKulhfFRQRODhts+IQlOYwk8Fd/NgFORvuqe9VffZydnYAsN4dCxCZmiiGNcsikfO5eK4+Zkdm7sfdOY6D+crJu/TGbY4w6pJ55sHp4Bbw/2Yom8BF9WTrvPQGNvwqgBVGZA7fE0g69psCJEGR4TNubk7UhSyAT0I8PJXkQZDKisASXxSSvgEHk2BMlWRs5szZsa3qsU7n+MqHfeIdw6qexBDniDKNwkYFRAVSaJ+K78UUkIFYkHedtOzjXKmsYPW4o64D3mkePHCOkBjFtcojHPz4s0PluR7HxcfqlYtqiqWP+uz1HfiDGZFwS3Uo0IA5ap8Ud7UVlixvLst1gzuXvmEkLF7sSwArnF34KAWIa0VnvRNHQEV/Kw/zAv3XUxkEolpGznt4rU7dk VDEzNS7m gK30Zb1m0gflvyN4qbS952vYOzkD5m0Pd7B9cABzZv2mSXc8CJoD+u4w9RQZwVPAdngx3ewqk5ah4d+r+GJnuDTwHVQ3dt2ShWi/mx6b+ACumclZpJ5Fo3xjmKs8cZB6TuPFWwli5RD8zB7KFgNT0lgxHnFlZ7O2LZ4/FNwlS3DtwAqRPZsxgeXAaf55YvnYWODlVF9YF69+qn+/dvUtbZqdyhQxMSoXHqIvPyxgdCtpB4JEtLWRz8xDZFy8g+NUsTkUlm+0KxJaHBff1r43VP21xJp8IxxwfeblgG5/Y6cIwdsPVXYd9hjRYeDhcwM1bNUeHnFulHBV26NYh647pBqKPr4d3h85wM/DR59YxhcMxWD972uD8saGPQfFRYngFgnb7vlOs5TxusJU= 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: --h9KvXQkczWY3GIVF Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 16, 2024 at 06:50:12PM +0000, Edgecombe, Rick P wrote: > On Wed, 2024-07-10 at 19:27 +0100, Mark Brown wrote: > > On Wed, Jul 10, 2024 at 12:36:21PM +0200, Florian Weimer wrote: > > > 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 generatio= n. > > > I assume it's currently missing because the kernel does not resume > > > execution using a regular return instruction.=A0 It would be really u= seful > > > 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 conte= xt > > > could be pushed instead).=A0 That would need some form of marker as w= ell. > > Right, we'd have to manually consume any extra address we put on the > > GCS.=A0 I'm not seeing any gagetisation issues with writing an extra va= lue > > 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? > Shadow stack has one main usage (security) and another less proven, but > interesting usage for backtracing.=A0I'm wary of adding things to the sha= dow stack > as they come up in an ad-hoc fashion, especially for the fuzzier usage.= =A0Do you > have a handle on everything the tracing usage would need? Yeah, the current instruction pointer seems fairly straightforward to idiomatically fit in there but going beyond that gets tricker. > But besides that I've wondered if there could be a security benefit to ad= ding > some fields of the sigframe (RIP being the prime one) to the shadow stack= , or a > cryptographic hash of the sigframe. One trick with trying to actually validate anything extra we put in there from the sigframe would be that one of the things a signal handler can do is modify the signal context - for the specific case of RIP that'd be an issue for rseq for example. --h9KvXQkczWY3GIVF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmaX4xoACgkQJNaLcl1U h9Cgxwf9EtoH1wDADGEHB812knHuhpaXQ+HApRHTVo5CjSDf2jXeTXGAeof7B8TM MLHNoO3uezt5r1bpHpC7gAruLzfAEs+G+rahhQswSuEDDGQLhcZga0SHFL2cmZpM SZ2Lk3725bJaoUzexEHk/8ZjpXnrzWXi+U/YoTi9PfcX6bUfVufG0hPr/xR8836n kKF9q2R93WTz8gIiIHpuUqgQ7jRjrDW5UIi0KhRobcLRKBhL5aYVQ1T9GVgwjA4v 7R3dDdrlAWQLJcjwjciJ3Ti6xSB2evfDt2FjmDE23My2AkO7dJebKhz7fABWCRbZ f2X9PmkSZlUHX26EuZIME4o9ENxnWg== =HySw -----END PGP SIGNATURE----- --h9KvXQkczWY3GIVF--