From: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
To: Mark Brown <broonie@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>
Cc: "Rick P. Edgecombe" <rick.p.edgecombe@intel.com>,
Deepak Gupta <debug@rivosinc.com>,
"H.J. Lu" <hjl.tools@gmail.com>,
Florian Weimer <fweimer@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
Valentin Schneider <vschneid@redhat.com>,
Christian Brauner <brauner@kernel.org>,
Shuah Khan <shuah@kernel.org>,
linux-kernel@vger.kernel.org, Will Deacon <will@kernel.org>,
Kees Cook <keescook@chromium.org>,
jannh@google.com, linux-kselftest@vger.kernel.org,
linux-api@vger.kernel.org, David Hildenbrand <david@redhat.com>
Subject: Re: [PATCH RFT v4 0/5] fork: Support shadow stacks in clone3()
Date: Fri, 1 Dec 2023 11:50:25 +0000 [thread overview]
Message-ID: <ZWnIgQgUW0Eyfcw9@arm.com> (raw)
In-Reply-To: <fce4c169-5d19-40e8-bc32-0abec9bb008e@sirena.org.uk>
The 11/30/2023 21:51, Mark Brown wrote:
> The concern Rick raised was that allowing user to pick the exact shadow
> stack pointer would allow userspace to corrupt or reuse the stack of an
> existing thread by starting a new thread with the shadow stack pointing
> into the existing shadow stack of that thread. While in isolation
note that this can be prevented by map_shadow_stack adding
a token that clone3 verifies.
> that's not too much more than what userspace could just do directly
> anyway it might compose with other issues to something more "interesting"
> (eg, I'd be a bit concerned about overlap with pkeys/POE though I've not
> thought through potential uses in detail).
>
> > I'm not against clone3() getting a shadow_stack_size argument but asking
> > some more questions. If we won't pass a pointer as well, is there any
> > advantage in expanding this syscall vs a specific prctl() option? Do we
> > need a different size per thread or do all threads have the same shadow
> > stack size? A new RLIMIT doesn't seem to map well though, it is more
> > like an upper limit rather than a fixed/default size (glibc I think uses
> > it for thread stacks but bionic or musl don't AFAIK).
>
> I don't know what the userspace patterns are likely to be here, it's
> possible a single value for each process might be fine but I couldn't
> say that confidently. I agree that a RLIMIT does seem like a poor fit.
user code can control the thread stack size per thread
and different size per thread happens in practice (even
in the libc e.g. timer_create with SIGEV_THREAD uses
different stack size than the dns resolver helper thread).
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
next prev parent reply other threads:[~2023-12-01 11:51 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-28 18:22 [PATCH RFT v4 0/5] fork: Support shadow stacks in clone3() Mark Brown
2023-11-28 18:22 ` [PATCH RFT v4 1/5] mm: Introduce ARCH_HAS_USER_SHADOW_STACK Mark Brown
2023-11-28 18:22 ` [PATCH RFT v4 2/5] fork: Add shadow stack support to clone3() Mark Brown
2023-11-28 21:23 ` Deepak Gupta
2023-11-29 13:05 ` Mark Brown
2023-12-05 0:26 ` Edgecombe, Rick P
2023-12-05 15:51 ` Mark Brown
2023-12-05 22:23 ` Edgecombe, Rick P
2023-12-06 18:24 ` Mark Brown
2023-11-28 18:22 ` [PATCH RFT v4 3/5] selftests/clone3: Factor more of main loop into test_clone3() Mark Brown
2023-11-28 18:22 ` [PATCH RFT v4 4/5] selftests/clone3: Allow tests to flag if -E2BIG is a valid error code Mark Brown
2023-11-28 18:22 ` [PATCH RFT v4 5/5] kselftest/clone3: Test shadow stack support Mark Brown
2023-12-05 0:10 ` Edgecombe, Rick P
2023-12-05 15:05 ` Mark Brown
2023-12-05 16:01 ` Edgecombe, Rick P
2023-12-05 16:43 ` Mark Brown
2023-12-05 22:31 ` Edgecombe, Rick P
2023-12-06 18:42 ` Mark Brown
2023-11-30 19:00 ` [PATCH RFT v4 0/5] fork: Support shadow stacks in clone3() Catalin Marinas
2023-11-30 21:51 ` Mark Brown
2023-11-30 23:37 ` Edgecombe, Rick P
2023-12-01 14:00 ` Mark Brown
2023-12-01 11:50 ` Szabolcs Nagy [this message]
2023-12-01 13:47 ` Mark Brown
2023-12-01 17:30 ` Catalin Marinas
2023-12-01 18:28 ` Mark Brown
2023-12-09 0:59 ` Robert O'Callahan
2023-12-09 1:06 ` 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=ZWnIgQgUW0Eyfcw9@arm.com \
--to=szabolcs.nagy@arm.com \
--cc=bp@alien8.de \
--cc=brauner@kernel.org \
--cc=bristot@redhat.com \
--cc=broonie@kernel.org \
--cc=bsegall@google.com \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=debug@rivosinc.com \
--cc=dietmar.eggemann@arm.com \
--cc=fweimer@redhat.com \
--cc=hjl.tools@gmail.com \
--cc=hpa@zytor.com \
--cc=jannh@google.com \
--cc=juri.lelli@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=rostedt@goodmis.org \
--cc=shuah@kernel.org \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=will@kernel.org \
--cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).