mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
	 "dietmar.eggemann@arm.com" <dietmar.eggemann@arm.com>,
	 "linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>,
	"shuah@kernel.org" <shuah@kernel.org>,
	 "Szabolcs.Nagy@arm.com" <Szabolcs.Nagy@arm.com>,
	"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>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"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>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
	 "vschneid@redhat.com" <vschneid@redhat.com>,
	"kees@kernel.org" <kees@kernel.org>,
	 "will@kernel.org" <will@kernel.org>,
	"hpa@zytor.com" <hpa@zytor.com>,
	 "jannh@google.com" <jannh@google.com>,
	"peterz@infradead.org" <peterz@infradead.org>,
	 "yury.khrustalev@arm.com" <yury.khrustalev@arm.com>,
	"bp@alien8.de" <bp@alien8.de>,
	 "wilco.dijkstra@arm.com" <wilco.dijkstra@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	 "bsegall@google.com" <bsegall@google.com>,
	"juri.lelli@redhat.com" <juri.lelli@redhat.com>,
	 "x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3()
Date: Fri, 27 Sep 2024 10:50:55 +0200	[thread overview]
Message-ID: <20240927-springen-fortpflanzen-34a303373088@brauner> (raw)
In-Reply-To: <158190d9-a4a6-4647-84e8-f4ae036d984b@sirena.org.uk>

On Wed, Aug 21, 2024 at 06:23:18PM GMT, Mark Brown wrote:
> On Wed, Aug 21, 2024 at 03:54:49PM +0000, Edgecombe, Rick P wrote:
> > On Wed, 2024-08-21 at 13:45 +0100, Mark Brown wrote:
> 
> > > It's entirely possible it just leaked.  My own attempts to dig through
> > > the archives haven't turned up anything on the subjecti either, it seems
> > > to have been there from the get go and just gone in without comment.
> > > Equally it could just be that people felt that this was a more tasteful
> > > way of specifying stacks, or that some future use was envisioned.
> 
> > Ok, well I'm suspicious, but won't object over it. The rest seems settled from
> > my side. I may try to attract some other x86 attention to that CMPXCHG helper,
> > but otherwise.
> 
> OK, I'll post what I've got (with the current ABI) today, incorporating
> your x86 fixes and the tighter validation and we can see what people
> think.  Perhaps Christian remembers what's going on there?

The legacy clone system call had required userspace to know in which
direction the stack was growing and then pass down the stack pointer
appropriately (e.g., parisc grows upwards).

And in fact, the old clone() system call did take an additional
stack_size argument on specific architectures. For example, on
microblaze.

Also, when clone3() was done we still had ia64 in the tree which had a
separate clone2() system call that also required a stack_size argument.

So userspace ended up with code like this or worse:

     #define __STACK_SIZE (8 * 1024 * 1024)
     pid_t sys_clone(int (*fn)(void *), void *arg, int flags, int *pidfd)
     {
             pid_t ret;
             void *stack;

             stack = malloc(__STACK_SIZE);
             if (!stack)
                     return -ENOMEM;

     #ifdef __ia64__
             ret = __clone2(fn, stack, __STACK_SIZE, flags | SIGCHLD, arg, pidfd);
     #elif defined(__parisc__) /* stack grows up */
             ret = clone(fn, stack, flags | SIGCHLD, arg, pidfd);
     #else
             ret = clone(fn, stack + __STACK_SIZE, flags | SIGCHLD, arg, pidfd);
     #endif
             return ret;
     }

So we talked to the glibc folks which preferred the kernel to do all
this nonsense for them as it has that knowledge.

My preference is to keep the api consistent and require a stack_size for
shadow stacks as well.

  parent reply	other threads:[~2024-09-27  8:51 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-19 19:24 [PATCH RFT v9 0/8] fork: Support shadow stacks in clone3() Mark Brown
2024-08-19 19:24 ` [PATCH RFT v9 1/8] Documentation: userspace-api: Add shadow stack API documentation Mark Brown
2024-08-19 19:24 ` [PATCH RFT v9 2/8] selftests: Provide helper header for shadow stack testing Mark Brown
2024-08-20 21:36   ` Edgecombe, Rick P
2024-08-19 19:24 ` [PATCH RFT v9 3/8] mm: Introduce ARCH_HAS_USER_SHADOW_STACK Mark Brown
2024-08-19 19:24 ` [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3() Mark Brown
2024-08-20 21:36   ` Edgecombe, Rick P
2024-08-20 23:34     ` Mark Brown
2024-08-20 23:57       ` Edgecombe, Rick P
2024-08-21  0:19         ` Mark Brown
2024-08-21  1:45           ` Edgecombe, Rick P
2024-08-21 12:45             ` Mark Brown
2024-08-21 15:54               ` Edgecombe, Rick P
2024-08-21 17:23                 ` Mark Brown
2024-08-21 18:05                   ` Catalin Marinas
2024-09-27  8:50                   ` Christian Brauner [this message]
2024-09-27 15:21                     ` Edgecombe, Rick P
2024-10-01 15:12                       ` Christian Brauner
2024-10-01 17:33                         ` Mark Brown
2024-10-01 23:03                           ` Edgecombe, Rick P
2024-10-02 13:42                             ` Mark Brown
2024-10-02 21:01                               ` Mark Brown
2024-10-02 21:25                                 ` Edgecombe, Rick P
2024-10-03 16:05                         ` Yury Khrustalev
2024-08-19 19:24 ` [PATCH RFT v9 5/8] selftests/clone3: Remove redundant flushes of output streams Mark Brown
2024-08-19 19:24 ` [PATCH RFT v9 6/8] selftests/clone3: Factor more of main loop into test_clone3() Mark Brown
2024-08-19 19:24 ` [PATCH RFT v9 7/8] selftests/clone3: Allow tests to flag if -E2BIG is a valid error code Mark Brown
2024-08-19 19:24 ` [PATCH RFT v9 8/8] selftests/clone3: Test shadow stack support 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=20240927-springen-fortpflanzen-34a303373088@brauner \
    --to=brauner@kernel.org \
    --cc=Szabolcs.Nagy@arm.com \
    --cc=bp@alien8.de \
    --cc=broonie@kernel.org \
    --cc=bsegall@google.com \
    --cc=catalin.marinas@arm.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=wilco.dijkstra@arm.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=yury.khrustalev@arm.com \
    /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

all inboxes | Powered by JetHome®