From: Yury Khrustalev <yury.khrustalev@arm.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc: "shuah@kernel.org" <shuah@kernel.org>,
"broonie@kernel.org" <broonie@kernel.org>,
"brauner@kernel.org" <brauner@kernel.org>,
"will@kernel.org" <will@kernel.org>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"adhemerval.zanella@linaro.org" <adhemerval.zanella@linaro.org>,
"nsz@port70.net" <nsz@port70.net>,
"dalias@libc.org" <dalias@libc.org>,
"debug@rivosinc.com" <debug@rivosinc.com>,
"fweimer@redhat.com" <fweimer@redhat.com>,
"libc-alpha@sourceware.org" <libc-alpha@sourceware.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"wilco.dijkstra@arm.com" <wilco.dijkstra@arm.com>,
"jeffxu@google.com" <jeffxu@google.com>,
"codonell@redhat.com" <codonell@redhat.com>,
"linux-kselftest@vger.kernel.org"
<linux-kselftest@vger.kernel.org>
Subject: Re: [PATCH RFC 0/3] arm64/gcs: Allow reuse of user managed shadow stacks
Date: Fri, 26 Sep 2025 16:07:58 +0100 [thread overview]
Message-ID: <aNasTpkYm8n1AHZ7@arm.com> (raw)
In-Reply-To: <760447dc3e5805bf5668e80a94bf32356e2eb2d3.camel@intel.com>
Hi,
On Thu, Sep 25, 2025 at 08:40:56PM +0000, Edgecombe, Rick P wrote:
> On Sun, 2025-09-21 at 14:21 +0100, Mark Brown wrote:
> > During the discussion of the clone3() support for shadow stacks concerns
> > were raised from the glibc side that since it is not possible to reuse
> > the allocated shadow stack[1]. This means that the benefit of being able
> > ...
> >
> Security-wise, it seems reasonable that if you are leaving a shadow stack, that
> you could leave a token behind. But for the userspace scheme to back up the SSP
> by doing a longjmp() or similar I have some doubts. IIRC there were some cross
> stack edge cases that we never figured out how to handle.
>
> As far as re-using allocated shadow stacks, there is always the option to enable
> WRSS (or similar) to write the shadow stack as well as longjmp at will.
>
> I think we should see a fuller solution from the glibc side before adding new
> kernel features like this. (apologies if I missed it).
What do you mean by "a fuller solution from the glibc side"? A solution
for re-using shadow stacks? Right now Glibc cannot do anything about
shadow stacks for new threads because clone3 interface doesn't allow it.
Thanks,
Yury
next prev parent reply other threads:[~2025-09-26 15:08 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-21 13:21 [PATCH RFC 0/3] arm64/gcs: Allow reuse of user managed shadow stacks Mark Brown
2025-09-21 13:21 ` [PATCH RFC 1/3] arm64/gcs: Support reuse of GCS for exited threads Mark Brown
2025-09-25 16:46 ` Catalin Marinas
2025-09-25 17:01 ` Mark Brown
2025-09-25 18:36 ` Catalin Marinas
2025-09-25 19:00 ` Mark Brown
2025-09-26 11:14 ` Catalin Marinas
2025-09-26 11:37 ` Mark Brown
2025-09-21 13:21 ` [PATCH RFC 2/3] kselftest/arm64: Validate PR_SHADOW_STACK_EXIT_TOKEN in basic-gcs Mark Brown
2025-09-21 13:21 ` [PATCH RFC 3/3] kselftest/arm64: Add PR_SHADOW_STACK_EXIT_TOKEN to gcs-locking Mark Brown
2025-09-25 20:40 ` [PATCH RFC 0/3] arm64/gcs: Allow reuse of user managed shadow stacks Edgecombe, Rick P
2025-09-25 23:22 ` Mark Brown
2025-09-25 23:58 ` Edgecombe, Rick P
2025-09-26 0:44 ` Mark Brown
2025-09-26 15:46 ` Edgecombe, Rick P
2025-09-26 16:09 ` Mark Brown
2025-09-29 18:37 ` Deepak Gupta
2025-09-26 15:07 ` Yury Khrustalev [this message]
2025-09-26 15:39 ` Edgecombe, Rick P
2025-09-26 16:03 ` Mark Brown
2025-09-26 19:17 ` Edgecombe, Rick P
2025-09-29 15:47 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aNasTpkYm8n1AHZ7@arm.com \
--to=yury.khrustalev@arm.com \
--cc=adhemerval.zanella@linaro.org \
--cc=brauner@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=codonell@redhat.com \
--cc=dalias@libc.org \
--cc=debug@rivosinc.com \
--cc=fweimer@redhat.com \
--cc=jeffxu@google.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=nsz@port70.net \
--cc=rick.p.edgecombe@intel.com \
--cc=shuah@kernel.org \
--cc=wilco.dijkstra@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.