linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "dietmar.eggemann@arm.com" <dietmar.eggemann@arm.com>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"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>,
	"bristot@redhat.com" <bristot@redhat.com>,
	"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>
Cc: "keescook@chromium.org" <keescook@chromium.org>,
	"jannh@google.com" <jannh@google.com>,
	"linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
	"will@kernel.org" <will@kernel.org>
Subject: Re: [PATCH RFT v4 2/5] fork: Add shadow stack support to clone3()
Date: Tue, 5 Dec 2023 00:26:57 +0000	[thread overview]
Message-ID: <61f80d032c6a630dd641c9b598b37c2eb40d51e8.camel@intel.com> (raw)
In-Reply-To: <20231128-clone3-shadow-stack-v4-2-8b28ffe4f676@kernel.org>

On Tue, 2023-11-28 at 18:22 +0000, Mark Brown wrote:
> -unsigned long shstk_alloc_thread_stack(struct task_struct *tsk,
> unsigned long clone_flags,
> -                                      unsigned long stack_size)
> +unsigned long shstk_alloc_thread_stack(struct task_struct *tsk,
> +                                      const struct kernel_clone_args
> *args)
>  {
>         struct thread_shstk *shstk = &tsk->thread.shstk;
> +       unsigned long clone_flags = args->flags;
>         unsigned long addr, size;
>  
>         /*
>          * If shadow stack is not enabled on the new thread, skip any
> -        * switch to a new shadow stack.
> +        * implicit switch to a new shadow stack and reject attempts
> to
> +        * explciitly specify one.
>          */
> -       if (!features_enabled(ARCH_SHSTK_SHSTK))
> -               return 0;
> +       if (!features_enabled(ARCH_SHSTK_SHSTK)) {
> +               if (args->shadow_stack_size)
> +                       return (unsigned long)ERR_PTR(-EINVAL);
>  
> -       /*
> -        * For CLONE_VFORK the child will share the parents shadow
> stack.
> -        * Make sure to clear the internal tracking of the thread
> shadow
> -        * stack so the freeing logic run for child knows to leave it
> alone.
> -        */
> -       if (clone_flags & CLONE_VFORK) {
> -               shstk->base = 0;
> -               shstk->size = 0;
>                 return 0;
>         }
>  
>         /*
> -        * For !CLONE_VM the child will use a copy of the parents
> shadow
> -        * stack.
> +        * If the user specified a shadow stack then do some basic
> +        * validation and use it, otherwise fall back to a default
> +        * shadow stack size if the clone_flags don't indicate an
> +        * allocation is unneeded.
>          */
> -       if (!(clone_flags & CLONE_VM))
> -               return 0;
> +       if (args->shadow_stack_size) {
> +               size = args->shadow_stack_size;
> +       } else {
> +               /*
> +                * For CLONE_VFORK the child will share the parents
> +                * shadow stack.  Make sure to clear the internal
> +                * tracking of the thread shadow stack so the freeing
> +                * logic run for child knows to leave it alone.
> +                */
> +               if (clone_flags & CLONE_VFORK) {
> +                       shstk->base = 0;
> +                       shstk->size = 0;
> +                       return 0;
> +               }
> +
> +               /*
> +                * For !CLONE_VM the child will use a copy of the
> +                * parents shadow stack.
> +                */
> +               if (!(clone_flags & CLONE_VM))
> +                       return 0;
> +
> +               size = args->stack_size;
> +
> +       }
>  
> -       size = adjust_shstk_size(stack_size);
> +       size = adjust_shstk_size(size);
>         addr = alloc_shstk(0, size, 0, false);

Hmm. I didn't test this, but in the copy_process(), copy_mm() happens
before this point. So the shadow stack would get mapped in current's MM
(i.e. the parent). So in the !CLONE_VM case with shadow_stack_size!=0
the SSP in the child will be updated to an area that is not mapped in
the child. I think we need to pass tsk->mm into alloc_shstk(). But such
an exotic clone usage does give me pause, regarding whether all of this
is premature.

Otherwise it looked ok from the x86/shstk perspective.

>         if (IS_ERR_VALUE(addr))
>                 return addr;


  parent reply	other threads:[~2023-12-05  0:27 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 [this message]
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
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=61f80d032c6a630dd641c9b598b37c2eb40d51e8.camel@intel.com \
    --to=rick.p.edgecombe@intel.com \
    --cc=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=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=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).