From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 61B57C36002 for ; Wed, 9 Apr 2025 14:31:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B55DB280057; Wed, 9 Apr 2025 10:31:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B04766B01FB; Wed, 9 Apr 2025 10:31:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9A647280057; Wed, 9 Apr 2025 10:31:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 7BEF76B01FA for ; Wed, 9 Apr 2025 10:31:40 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 53808160D23 for ; Wed, 9 Apr 2025 14:31:40 +0000 (UTC) X-FDA: 83314743960.07.F26054A Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) by imf18.hostedemail.com (Postfix) with ESMTP id 3C8E61C0003 for ; Wed, 9 Apr 2025 14:31:38 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=MuZTybdm; spf=pass (imf18.hostedemail.com: domain of debug@rivosinc.com designates 209.85.210.180 as permitted sender) smtp.mailfrom=debug@rivosinc.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744209098; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0FeDV1r7xH9rXEgLql5cKaWwHnmYxryb4t964mCAMYs=; b=vQUzS18v90a40673pkEaxgCbKWqBQcUzOei9r4NegIrElUtVRd/zFxHRy5goIoi6LKG7cZ DqBP2rPP7nrrfbBFnWD4EGdAFXI2utE4atD9XYK1JNKddZJfUNes0n9lrlrNj5GXXwd0JE /h4HjTRfE796rUyN6Op3hCk5ops7EFE= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=MuZTybdm; spf=pass (imf18.hostedemail.com: domain of debug@rivosinc.com designates 209.85.210.180 as permitted sender) smtp.mailfrom=debug@rivosinc.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744209098; a=rsa-sha256; cv=none; b=xQStV5dshcY6EuAJ3aQ72VgPduca9ihja08faOe2CtpVfVTAWdHHAjmHTfhVbfL5KTN48E PvZPITq8R6bfoIqUUVDvrV3TKU62a28F4UDVNYDVH/QvfRS4tP781PEmsiLFNGLDKNdJ6t WUD5sqbGfzAufiZJNKjMZ7AiBXv8mIU= Received: by mail-pf1-f180.google.com with SMTP id d2e1a72fcca58-736c1cf75e4so5954715b3a.2 for ; Wed, 09 Apr 2025 07:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1744209097; x=1744813897; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=0FeDV1r7xH9rXEgLql5cKaWwHnmYxryb4t964mCAMYs=; b=MuZTybdm/7cn3oxBBPA8IgbH5+Pc5nF7rLft2YgmzDaojOhkaFJE1IhZ5vT7gafYTo pKD2wXnrD0x5j/JM5dAOqW54Szdgch0A2CFtdGBOC8QW7wHcdnZuArrdXdI17Ga4F+Gr AhE7m8VHloez0jToa1ypTOS4pgyowoXWEMu5klklO0aKFrXJ9+nHUW6kSjEiicTBV01N TKmIg+cWQUXcA/TNRyQ8Y0K4+EnzPvJoE4RTj72+Pm6ncfg8NaBhuGFaij+wmTMlEljZ EUpi6W3gDo0MSBJNU+TSSG/Gx/9Tszt2NIjZRZ49MYvfx9EzFWxqTq1UUXJq4/LjMHFf DRxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744209097; x=1744813897; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0FeDV1r7xH9rXEgLql5cKaWwHnmYxryb4t964mCAMYs=; b=NgdpL8pgQIqlepMZsTBkA2Z07xLHe5w0wS8En5BP4TB0Na1PpuilQXGjLdNLSFeQ0+ K6bfok3oCXBzMGNoaqBd6Dvsy5x5Ath/amhNDWnRbCFOsGa3mFNOiApQfHrHqKpUw7W3 MnIw0L2GFQbuSvNyv466skBini9gNPqeA8N2YhxyHDOOLrZB81xJbsgnCuZcQXrMyYWY gqwtB7t64AwQzGbXZ8/3Z8rv5lqT9Ii1YE9W+KMv6zjlajj7Rt6YIvo3ikDB6N9KI8Gc o1i1XrNsygwSHPZkkWj4AvDtZmwdf6qYn5E+88XKfcE9jcZE1g568JMA9a7Fju8uX4MA Qo8Q== X-Forwarded-Encrypted: i=1; AJvYcCUyOWD/76Wnpyl1vtRgNg7ui+GfkEWNhVQHeax/5Jm1d4t3FdlaEUGSrqXBpGutoYfdbBhMJvGCAA==@kvack.org X-Gm-Message-State: AOJu0Ywooira9Gc5p7PCDl2YU9CRNVhPbbtLei/DUCAs9JcBscWSVnsR 9jb2csVid2iStT8jqsIzdnnVM9WmPhTnBzCOIy7t5YBDfW6IUV1S98yp/bM8LjQ= X-Gm-Gg: ASbGnctkeWSmwM8UTHDQ8ezDg0ZPuo/diNu7RWPGOvWqfhDzESdtVv3Sg0KSvOHkMCk PR6gOBXwYMSd5sXSqYChanQ6O0u+8q640MTSp/Sh8/a0Lza5IyOXL12noPFhlt7Qlqy9Q/sVg5q dTcdlDTpSKtyFmE21KvoJkZmDRaJqvScBNR7XbanAvtfmrnN2BJs8Bms+T+vOyPqbACOOBAXuop ElQCaKn7Rup9Y5CXoqbtCPAdAZzuuccpp6mEzdjV39QkzqpravmzMLsvzpfY+4c0zlc0RbWwIkP sBj8RVRhNN6bNXLHpuqDeNv/dUQ3pqNd4v1rc+cGAW9+e4mASYA= X-Google-Smtp-Source: AGHT+IED3nMyjC/xp6jU4TVM3YQVG77c60p2bmYnTCRDcF0CpknaypXvboWdda5bTGdKDnI+U9C9uQ== X-Received: by 2002:a05:6a00:1897:b0:739:4723:c4d7 with SMTP id d2e1a72fcca58-73bae54facfmr3971870b3a.22.1744209096781; Wed, 09 Apr 2025 07:31:36 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-73bb1d69767sm1382951b3a.78.2025.04.09.07.31.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Apr 2025 07:31:36 -0700 (PDT) Date: Wed, 9 Apr 2025 07:31:32 -0700 From: Deepak Gupta To: Alexandre Ghiti Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Lorenzo Stoakes , Paul Walmsley , Palmer Dabbelt , Albert Ou , Conor Dooley , Rob Herring , Krzysztof Kozlowski , Arnd Bergmann , Christian Brauner , Peter Zijlstra , Oleg Nesterov , Eric Biederman , Kees Cook , Jonathan Corbet , Shuah Khan , Jann Horn , Conor Dooley , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, alistair.francis@wdc.com, richard.henderson@linaro.org, jim.shu@sifive.com, andybnac@gmail.com, kito.cheng@sifive.com, charlie@rivosinc.com, atishp@rivosinc.com, evan@rivosinc.com, cleger@rivosinc.com, alexghiti@rivosinc.com, samitolvanen@google.com, broonie@kernel.org, rick.p.edgecombe@intel.com, Zong Li Subject: Re: [PATCH v12 11/28] riscv/shstk: If needed allocate a new shadow stack on clone Message-ID: References: <20250314-v5_user_cfi_series-v12-0-e51202b53138@rivosinc.com> <20250314-v5_user_cfi_series-v12-11-e51202b53138@rivosinc.com> <3f9c48a6-1256-4e52-a26a-7f80f3b7c05a@ghiti.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <3f9c48a6-1256-4e52-a26a-7f80f3b7c05a@ghiti.fr> X-Rspamd-Queue-Id: 3C8E61C0003 X-Rspamd-Server: rspam05 X-Rspam-User: X-Stat-Signature: 461yjn7fndjzpndqr573jn9dipad8iy9 X-HE-Tag: 1744209098-340832 X-HE-Meta: U2FsdGVkX19bGlh0or1m5e7P8VH3WGPAp+lRhvKRWTS1av/6EKDrP6CY1dBjuErXYkcr42yDemTKHWN93JVvjomf1noX1fh3l+7VoJfw9Irj5999xAlXFwIA6U2gHhecF8of5L9YqxKT27+eHvZiW6FiyC/CxLk1JNe+ELLRFxj7H+nNrDZHklkJdA9CppzI1aLLE4v1yRNbL5VK8exrsp75NhB39xRBfXcaQoEDga8INU06HENcqhcsdCPmjJ2Dd3i0Oa+TIoLVkzUPzowbtRLm3fmalQ4avYY6+bpSb/6FEowAqLLjxfFe5oUcBlfkCSQ9o4sheXKQG+9JtytIWSgExv+g2XW0UKt0MdZC20cT51yyLWb43PTHqmfY91ulvV5lB9lKBhHnGwHtZPMqboHwQNUbA1PDeeRDYnd4kRFqJcPSMLbkZWMouoE51o3LAE+q0y9v2fw1OGxcyaTwM+jBiI9wxSSJgx/tuRqwIPRiJEYZ4iF4J18ETRtxN59d24K5ZPeWLBCDL0aacI4S+JsgsIxNWUWANMmKyz9NcmIL3FNetFyzx/W42l+br2BYGFNV/8+I8CdDKMVmWdDzC51NF+JnMBs+GaAgArioe0egDihcJXaZezFiOH8nToy6q6nqngm5mTXvsWtVHwFnn6C3z+PECv9BM9CGyiIg+9cx0VpTz1U1qd/uUdTuVfW4gPa5ERfym1YXR6zZP7JWrX/bH9S9CO1IaH1n+QfLZW7RuWx4u+uFNbAsX9GCu1vYp2uKWoNdjQYRkxCmH61vyBy3ltRs7KlzhIiyKS5xlqqfwyWQylowopzfjWfMdKN1vZuQunxI6ZyQ+YYCc8WYUto0oKdqHdieJ1msiS0dkCHJsTRuHbam/wuaD4Qyx8IBWoSS9xbxENKzHrruEZun0InU7GzXWQ8Sdl/Zx3+o5AcWPDRSAl4A3bb49Pq91ZEMI324hGdKtK4mkFmdk9l mMxYdjbW Y12AbjtSPlwlVXveTmPAmMUCQMrGPDvxz/xV+7HAUVvwMhKG7Zq9K3rgfF1uTJAdHghz4VpaV/9UNmEQKRv6V+pONWxMnLMI2u4qqHab6AOlmnpuyngGb1u8b/MouUxjNXDKow98xPnQ4FMeE2ZmpSoNzJyBRb4tU/s+XBC9r9DiA4LJ0jIIhJZMxJCiFMsi3QGnmQXz7yoVDiaPlltli9i481qMP6TeOYd/FsKyPes0cg04Exfw2wZvRU9tyMpSnrGnvIOEojI22OfPNEfza6YLwJFDyM46HwUYXec0vsyabz+L0zRpuIhk3/UhpP3GNqzF06M+MCrb3MUilme2N7eOa5IHTEzuSlj+o3TK1sfGWo59HZeLgF1oAHgvP4uR75i+/fm8DCwiz4KBYMVPKU8vp3mV+tiJc1ZL6Rkk03M28jcoD0G3CfR/iTVemFtQ/NTtKduiMv2f1v1Zlz+OZaPVWl7D1d+9ILv0GdbtUyqNE9j0mrN1VGSoHiWT3+uNf8lYP/zCBK4v0JHzYA1JjzrWnvzyU/t8kFBs8WV+r7v037FcHi/6CsyAGSYX3Jx2JpMPsteo8JaxJFlE= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Apr 08, 2025 at 12:51:45PM +0200, Alexandre Ghiti wrote: > >On 14/03/2025 22:39, Deepak Gupta wrote: >>Userspace specifies CLONE_VM to share address space and spawn new thread. >>`clone` allow userspace to specify a new stack for new thread. However >>there is no way to specify new shadow stack base address without changing >>API. This patch allocates a new shadow stack whenever CLONE_VM is given. >> >>In case of CLONE_VFORK, parent is suspended until child finishes and thus >>can child use parent shadow stack. In case of !CLONE_VM, COW kicks in >>because entire address space is copied from parent to child. >> >>`clone3` is extensible and can provide mechanisms using which shadow stack >>as an input parameter can be provided. This is not settled yet and being >>extensively discussed on mailing list. Once that's settled, this commit >>will adapt to that. > > >What's the status of this discussion? Can you provide a Link to it? It's ongoing right now at v15 https://lore.kernel.org/all/20250408-clone3-shadow-stack-v15-0-3fa245c6e3be@kernel.org/ > > >> >>Reviewed-by: Zong Li >>Signed-off-by: Deepak Gupta >>--- >> arch/riscv/include/asm/mmu_context.h | 7 ++ >> arch/riscv/include/asm/usercfi.h | 25 ++++++++ >> arch/riscv/kernel/process.c | 9 +++ >> arch/riscv/kernel/usercfi.c | 120 +++++++++++++++++++++++++++++++++++ >> 4 files changed, 161 insertions(+) >> >>diff --git a/arch/riscv/include/asm/mmu_context.h b/arch/riscv/include/asm/mmu_context.h >>index 8c4bc49a3a0f..dbf27a78df6c 100644 >>--- a/arch/riscv/include/asm/mmu_context.h >>+++ b/arch/riscv/include/asm/mmu_context.h >>@@ -48,6 +48,13 @@ static inline unsigned long mm_untag_mask(struct mm_struct *mm) >> } >> #endif >>+#define deactivate_mm deactivate_mm >>+static inline void deactivate_mm(struct task_struct *tsk, >>+ struct mm_struct *mm) >>+{ >>+ shstk_release(tsk); >>+} >>+ >> #include >> #endif /* _ASM_RISCV_MMU_CONTEXT_H */ >>diff --git a/arch/riscv/include/asm/usercfi.h b/arch/riscv/include/asm/usercfi.h >>index 5f2027c51917..82d28ac98d76 100644 >>--- a/arch/riscv/include/asm/usercfi.h >>+++ b/arch/riscv/include/asm/usercfi.h >>@@ -8,6 +8,9 @@ >> #ifndef __ASSEMBLY__ >> #include >>+struct task_struct; >>+struct kernel_clone_args; >>+ >> #ifdef CONFIG_RISCV_USER_CFI >> struct cfi_status { >> unsigned long ubcfi_en : 1; /* Enable for backward cfi. */ >>@@ -17,6 +20,28 @@ struct cfi_status { >> unsigned long shdw_stk_size; /* size of shadow stack */ >> }; >>+unsigned long shstk_alloc_thread_stack(struct task_struct *tsk, >>+ const struct kernel_clone_args *args); >>+void shstk_release(struct task_struct *tsk); >>+void set_shstk_base(struct task_struct *task, unsigned long shstk_addr, unsigned long size); >>+unsigned long get_shstk_base(struct task_struct *task, unsigned long *size); >>+void set_active_shstk(struct task_struct *task, unsigned long shstk_addr); >>+bool is_shstk_enabled(struct task_struct *task); >>+ >>+#else >>+ >>+#define shstk_alloc_thread_stack(tsk, args) 0 >>+ >>+#define shstk_release(tsk) >>+ >>+#define get_shstk_base(task, size) 0UL >>+ >>+#define set_shstk_base(task, shstk_addr, size) >>+ >>+#define set_active_shstk(task, shstk_addr) >>+ >>+#define is_shstk_enabled(task) false >>+ >> #endif /* CONFIG_RISCV_USER_CFI */ >> #endif /* __ASSEMBLY__ */ >>diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c >>index 7c244de77180..99acb6342a37 100644 >>--- a/arch/riscv/kernel/process.c >>+++ b/arch/riscv/kernel/process.c >>@@ -29,6 +29,7 @@ >> #include >> #include >> #include >>+#include >> #if defined(CONFIG_STACKPROTECTOR) && !defined(CONFIG_STACKPROTECTOR_PER_TASK) >> #include >>@@ -211,6 +212,7 @@ int copy_thread(struct task_struct *p, const struct kernel_clone_args *args) >> unsigned long clone_flags = args->flags; >> unsigned long usp = args->stack; >> unsigned long tls = args->tls; >>+ unsigned long ssp = 0; >> struct pt_regs *childregs = task_pt_regs(p); >> /* Ensure all threads in this mm have the same pointer masking mode. */ >>@@ -229,11 +231,18 @@ int copy_thread(struct task_struct *p, const struct kernel_clone_args *args) >> p->thread.s[0] = (unsigned long)args->fn; >> p->thread.s[1] = (unsigned long)args->fn_arg; >> } else { >>+ /* allocate new shadow stack if needed. In case of CLONE_VM we have to */ >>+ ssp = shstk_alloc_thread_stack(p, args); >>+ if (IS_ERR_VALUE(ssp)) >>+ return PTR_ERR((void *)ssp); >>+ >> *childregs = *(current_pt_regs()); >> /* Turn off status.VS */ >> riscv_v_vstate_off(childregs); >> if (usp) /* User fork */ >> childregs->sp = usp; >>+ /* if needed, set new ssp */ >>+ ssp ? set_active_shstk(p, ssp) : 0; > > >The use of the ternary here is weird, can you change that to a if >statement? > > >> if (clone_flags & CLONE_SETTLS) >> childregs->tp = tls; >> childregs->a0 = 0; /* Return value of fork() */ >>diff --git a/arch/riscv/kernel/usercfi.c b/arch/riscv/kernel/usercfi.c >>index 24022809a7b5..73cf87dab186 100644 >>--- a/arch/riscv/kernel/usercfi.c >>+++ b/arch/riscv/kernel/usercfi.c >>@@ -19,6 +19,41 @@ >> #define SHSTK_ENTRY_SIZE sizeof(void *) >>+bool is_shstk_enabled(struct task_struct *task) >>+{ >>+ return task->thread_info.user_cfi_state.ubcfi_en ? true : false; >>+} >>+ >>+void set_shstk_base(struct task_struct *task, unsigned long shstk_addr, unsigned long size) >>+{ >>+ task->thread_info.user_cfi_state.shdw_stk_base = shstk_addr; >>+ task->thread_info.user_cfi_state.shdw_stk_size = size; >>+} >>+ >>+unsigned long get_shstk_base(struct task_struct *task, unsigned long *size) >>+{ >>+ if (size) >>+ *size = task->thread_info.user_cfi_state.shdw_stk_size; >>+ return task->thread_info.user_cfi_state.shdw_stk_base; >>+} >>+ >>+void set_active_shstk(struct task_struct *task, unsigned long shstk_addr) >>+{ >>+ task->thread_info.user_cfi_state.user_shdw_stk = shstk_addr; >>+} >>+ >>+/* >>+ * If size is 0, then to be compatible with regular stack we want it to be as big as >>+ * regular stack. Else PAGE_ALIGN it and return back >>+ */ >>+static unsigned long calc_shstk_size(unsigned long size) >>+{ >>+ if (size) >>+ return PAGE_ALIGN(size); >>+ >>+ return PAGE_ALIGN(min_t(unsigned long long, rlimit(RLIMIT_STACK), SZ_4G)); >>+} >>+ >> /* >> * Writes on shadow stack can either be `sspush` or `ssamoswap`. `sspush` can happen >> * implicitly on current shadow stack pointed to by CSR_SSP. `ssamoswap` takes pointer to >>@@ -142,3 +177,88 @@ SYSCALL_DEFINE3(map_shadow_stack, unsigned long, addr, unsigned long, size, unsi >> return allocate_shadow_stack(addr, aligned_size, size, set_tok); >> } >>+ >>+/* >>+ * This gets called during clone/clone3/fork. And is needed to allocate a shadow stack for >>+ * cases where CLONE_VM is specified and thus a different stack is specified by user. We >>+ * thus need a separate shadow stack too. How does separate shadow stack is specified by >>+ * user is still being debated. Once that's settled, remove this part of the comment. >>+ * This function simply returns 0 if shadow stack are not supported or if separate shadow >>+ * stack allocation is not needed (like in case of !CLONE_VM) >>+ */ >>+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; >>+} >>+ >>+void shstk_release(struct task_struct *tsk) >>+{ >>+ unsigned long base = 0, size = 0; >>+ /* If shadow stack is not supported or not enabled, nothing to release */ >>+ if (!cpu_supports_shadow_stack() || !is_shstk_enabled(tsk)) >>+ return; >>+ >>+ /* >>+ * When fork() with CLONE_VM fails, the child (tsk) already has a >>+ * shadow stack allocated, and exit_thread() calls this function to >>+ * free it. In this case the parent (current) and the child share >>+ * the same mm struct. Move forward only when they're same. >>+ */ >>+ if (!tsk->mm || tsk->mm != current->mm) >>+ return; >>+ >>+ /* >>+ * We know shadow stack is enabled but if base is NULL, then >>+ * this task is not managing its own shadow stack (CLONE_VFORK). So >>+ * skip freeing it. >>+ */ >>+ base = get_shstk_base(tsk, &size); >>+ if (!base) >>+ return; >>+ >>+ vm_munmap(base, size); >>+ set_shstk_base(tsk, 0, 0); >>+} >>