On Sat, Dec 09, 2023 at 01:59:16PM +1300, Robert O'Callahan wrote:
> overriding clone_args::shadow_stack_size to zero in the call to
> clone3(), instead having the replay task call map_shadow_stack() to
> put the the shadow stack in the right place, and then setting its SSP
> via ptrace. Will that
On Wed, 29 Nov 2023 at 07:31, Mark Brown wrote:
> Since clone3() is readily extensible let's add support for specifying a
> shadow stack when creating a new thread or process in a similar manner
> to how the normal stack is specified, keeping the current implicit
> allocation behaviour if one is n
On Fri, Dec 01, 2023 at 05:30:22PM +, Catalin Marinas wrote:
> Another concern I had was that map_shadow_stack() currently takes
> a flags arg (though only one flag) while the clone/clone3() allocate the
> shadow stack with an implicit configuration (other than size). Would
> map_shadow_stack(
Thanks all for the clarification.
On Thu, Nov 30, 2023 at 09:51:04PM +, Mark Brown wrote:
> On Thu, Nov 30, 2023 at 07:00:58PM +, Catalin Marinas wrote:
> > My hope when looking at the arm64 patches was that we can completely
> > avoid the kernel allocation/deallocation of the shadow stack
On Thu, Nov 30, 2023 at 11:37:42PM +, Edgecombe, Rick P wrote:
> On Thu, 2023-11-30 at 21:51 +, Mark Brown wrote:
> > On Thu, Nov 30, 2023 at 07:00:58PM +, Catalin Marinas wrote:
> > explicitly request a new shadow stack. There was some corner case
> > with
> > IIRC posix_nspawn() men
On Fri, Dec 01, 2023 at 11:50:25AM +, Szabolcs Nagy wrote:
> 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 thre
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 t
On Thu, 2023-11-30 at 21:51 +, Mark Brown wrote:
> On Thu, Nov 30, 2023 at 07:00:58PM +, Catalin Marinas wrote:
>
> > My hope when looking at the arm64 patches was that we can
> > completely
> > avoid the kernel allocation/deallocation of the shadow stack since
> > it
> > doesn't need to d
On Thu, Nov 30, 2023 at 07:00:58PM +, Catalin Marinas wrote:
> My hope when looking at the arm64 patches was that we can completely
> avoid the kernel allocation/deallocation of the shadow stack since it
> doesn't need to do this for the normal stack either. Could someone
> please summarise wh
Hi Mark,
Thanks for putting this together and sorry it took me some time to catch
up (well, still not fully, so rather more questions below).
On Tue, Nov 28, 2023 at 06:22:38PM +, Mark Brown wrote:
> Since clone3() is readily extensible let's add support for specifying a
> shadow stack when c
The kernel has recently added support for shadow stacks, currently
x86 only using their CET feature but both arm64 and RISC-V have
equivalent features (GCS and Zicfiss respectively), I am actively
working on GCS[1]. With shadow stacks the hardware maintains an
additional stack containing only the
11 matches
Mail list logo
