From: Catalin Marinas <catalin.marinas@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
"dietmar.eggemann@arm.com" <dietmar.eggemann@arm.com>,
"Szabolcs.Nagy@arm.com" <Szabolcs.Nagy@arm.com>,
"brauner@kernel.org" <brauner@kernel.org>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"debug@rivosinc.com" <debug@rivosinc.com>,
"mgorman@suse.de" <mgorman@suse.de>,
"vincent.guittot@linaro.org" <vincent.guittot@linaro.org>,
"fweimer@redhat.com" <fweimer@redhat.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"hjl.tools@gmail.com" <hjl.tools@gmail.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"vschneid@redhat.com" <vschneid@redhat.com>,
"shuah@kernel.org" <shuah@kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"bp@alien8.de" <bp@alien8.de>,
"bsegall@google.com" <bsegall@google.com>,
"x86@kernel.org" <x86@kernel.org>,
"juri.lelli@redhat.com" <juri.lelli@redhat.com>,
"jannh@google.com" <jannh@google.com>,
"linux-kselftest@vger.kernel.org"
<linux-kselftest@vger.kernel.org>,
"kees@kernel.org" <kees@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
"will@kernel.org" <will@kernel.org>
Subject: Re: [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3()
Date: Fri, 16 Aug 2024 16:29:13 +0100 [thread overview]
Message-ID: <Zr9wSa2Yyq-MCWVq@arm.com> (raw)
In-Reply-To: <c644d64b-f7d0-47de-b5ba-ae2ac1b46e1b@sirena.org.uk>
On Fri, Aug 16, 2024 at 11:51:57AM +0100, Mark Brown wrote:
> On Fri, Aug 16, 2024 at 09:44:46AM +0100, Catalin Marinas wrote:
> > We could, in theory, consume this token in the parent before the child
> > mm is created. The downside is that if a parent forks multiple
> > processes using the same shadow stack, it will have to set the token
> > each time. I'd be fine with this, that's really only for the mostly
> > theoretical case where one doesn't use CLONE_VM and still want a
> > separate stack and shadow stack.
>
> I originally implemented things that way but people did complain about
> the !CLONE_VM case, which does TBH seem reasonable. Note that the
> parent won't as standard be able to set the token again - since the
> shadow stack is not writable to userspace by default it'd instead need
> to allocate a whole new shadow stack for each child.
Ah, good point.
> I change back to parsing the token in the parent but I don't want to end
> up in a cycle of bouncing between the two implementations depending on
> who's reviewed the most recent version.
You and others spent a lot more time looking at shadow stacks than me.
I'm not necessarily asking to change stuff but rather understand the
choices made.
--
Catalin
next prev parent reply other threads:[~2024-08-16 15:29 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-08 8:15 [PATCH RFT v8 0/9] fork: Support shadow stacks in clone3() Mark Brown
2024-08-08 8:15 ` [PATCH RFT v8 1/9] Documentation: userspace-api: Add shadow stack API documentation Mark Brown
2024-08-14 10:40 ` Catalin Marinas
2024-08-08 8:15 ` [PATCH RFT v8 2/9] selftests: Provide helper header for shadow stack testing Mark Brown
2024-08-08 8:15 ` [PATCH RFT v8 3/9] mm: Introduce ARCH_HAS_USER_SHADOW_STACK Mark Brown
2024-08-14 10:41 ` Catalin Marinas
2024-08-08 8:15 ` [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3() Mark Brown
2024-08-09 18:19 ` Catalin Marinas
2024-08-09 23:06 ` Mark Brown
2024-08-13 16:25 ` Catalin Marinas
2024-08-13 18:58 ` Mark Brown
2024-08-14 9:38 ` Catalin Marinas
2024-08-14 13:20 ` Mark Brown
2024-08-15 0:18 ` Edgecombe, Rick P
2024-08-15 14:24 ` Mark Brown
2024-08-16 8:44 ` Catalin Marinas
2024-08-16 10:51 ` Mark Brown
2024-08-16 15:29 ` Catalin Marinas [this message]
2024-08-16 15:46 ` Mark Brown
2024-08-16 14:52 ` Edgecombe, Rick P
2024-08-16 15:30 ` Mark Brown
2024-08-16 15:38 ` Catalin Marinas
2024-08-16 17:06 ` Mark Brown
2024-08-16 17:08 ` Jann Horn
2024-08-16 17:17 ` Mark Brown
2024-08-08 8:15 ` [PATCH RFT v8 5/9] selftests/clone3: Remove redundant flushes of output streams Mark Brown
2024-08-08 8:15 ` [PATCH RFT v8 6/9] selftests/clone3: Factor more of main loop into test_clone3() Mark Brown
2024-08-08 8:15 ` [PATCH RFT v8 7/9] selftests/clone3: Explicitly handle child exits due to signals Mark Brown
2024-08-08 8:15 ` [PATCH RFT v8 8/9] selftests/clone3: Allow tests to flag if -E2BIG is a valid error code Mark Brown
2024-08-08 8:15 ` [PATCH RFT v8 9/9] selftests/clone3: Test shadow stack support Mark Brown
2024-08-08 17:54 ` [PATCH RFT v8 0/9] fork: Support shadow stacks in clone3() Kees Cook
2024-08-15 0:19 ` Edgecombe, Rick P
2024-08-16 15:52 ` Jann Horn
2024-08-16 16:19 ` 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=Zr9wSa2Yyq-MCWVq@arm.com \
--to=catalin.marinas@arm.com \
--cc=Szabolcs.Nagy@arm.com \
--cc=bp@alien8.de \
--cc=brauner@kernel.org \
--cc=broonie@kernel.org \
--cc=bsegall@google.com \
--cc=dave.hansen@linux.intel.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=kees@kernel.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 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.