Re: [PATCH v6 16/33] riscv/shstk: If needed allocate a new shadow stack on clone

On Tue, 2024-10-08 at 15:36 -0700, Deepak Gupta wrote:

+unsigned long shstk_alloc_thread_stack(struct task_struct *tsk,

• 			   const struct kernel_clone_args *args)
  

+{

• unsigned long addr, size;
• /* If shadow stack is not supported, return 0 */
• if (!cpu_supports_shadow_stack())

• return 0;
  

• /*

• * If shadow stack is not enabled on the new thread, skip any
  

• * switch to a new shadow stack.
  

• */
  

• if (!is_shstk_enabled(tsk))

• return 0;
  

• /*

• * For CLONE_VFORK the child will share the parents shadow stack.
  

• * Set base = 0 and size = 0, this is special means to track this state
  

• * so the freeing logic run for child knows to leave it alone.
  

• */
  

• if (args->flags & CLONE_VFORK) {

• set_shstk_base(tsk, 0, 0);
  

• return 0;
  

• }
• /*

• * For !CLONE_VM the child will use a copy of the parents shadow
  

• * stack.
  

• */
  

• if (!(args->flags & CLONE_VM))

• return 0;
  

• /*

• * reaching here means, CLONE_VM was specified and thus a separate shadow
  

• * stack is needed for new cloned thread. Note: below allocation is happening
  

• * using current mm.
  

• */
  

• size = calc_shstk_size(args->stack_size);
• addr = allocate_shadow_stack(0, size, 0, false);
• if (IS_ERR_VALUE(addr))

• return addr;
  

• set_shstk_base(tsk, addr, size);
• return addr + size;

+}

A lot of this patch and the previous one is similar to x86's and arm's. It great that we can have consistency around this behavior.

There might be enough consistency to refactor some of the arch code into a kernel/shstk.c.

Should we try?