From patchwork Thu Aug 22 01:15:26 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Brown X-Patchwork-Id: 13772459 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9919BC52D6F for ; Thu, 22 Aug 2024 01:31:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:In-Reply-To:References:Message-Id :MIME-Version:Subject:Date:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=n41o8tlyYEzNSe4rxTFS+N3LddRbmd4JyNXd9ki6lnk=; b=xW0gHKAxFNHaBb Qwcn5xtIG0VsgBMzh2vLURF5rhAujD3gSxp7lyAc94aXR0uOyOPb1YOy6iP4353VQE376kn3Oe06x 1T2d86wI7q35+90AeITnNSV/pkx6JNiEh4VfcXgNEbyLNo2GB+Mw228jndCbvI7G0/XaaNRYnOPXl bJrxMBS9MLYFUR1InpxlOpRzkuwuzEnY9EJ0xdeXBhwswYuUIUmIrdd5n9Up67U+rOtP+WbjntR3y aYRt9kABsvW4SohLJFh4JvxClORDx5Fx6SKrjLz+Jzg/W/Xa+JvuuLBPDQDIg473koyP+z/+gIp+Q aHpKzVPrSLdWYYnGarTQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgwfy-0000000Awl1-470H; Thu, 22 Aug 2024 01:31:46 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgwVJ-0000000Asrw-2jIF; Thu, 22 Aug 2024 01:20:47 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id E7CB960FE8; Thu, 22 Aug 2024 01:20:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5837FC32781; Thu, 22 Aug 2024 01:20:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724289644; bh=kXO2GCPjz2S4M/TO1zkwKAs7nkqAlyHosyHP175ZITc=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=NaYbf4coFOlLrG2dAibV7pBvMyx4JDv93vJ1RN5yZgKnTsT0LKjizxRQFsnLXc7ni 3c6Ka9YUXWQzYr7aYO41AkVGYgEFPS+NQLfFED+bGqnnWcPy704vjGLzr/l9kFfXrm KbBBPl00BgaD3OunTXUjrXZYzhmCinTKWhJrinLoPlACm7cPMNUBKZ7APxHOuq1vTq K9bz41XRDSzyQE0Y04SmBZiEmIMo6LQSseYY4rUAEhDxMVeB9Q6GZGUvPwqKUgR2Z0 wRVW+/BLnVdlG0MZrY17HLJoX7GrW4vjHQ9PX5g3FqZcmDN1b+3i/WgbAi+23MuJzY 0yC/Aj21Bh+YQ== From: Mark Brown Date: Thu, 22 Aug 2024 02:15:26 +0100 Subject: [PATCH v11 23/39] arm64/mm: Implement map_shadow_stack() MIME-Version: 1.0 Message-Id: <20240822-arm64-gcs-v11-23-41b81947ecb5@kernel.org> References: <20240822-arm64-gcs-v11-0-41b81947ecb5@kernel.org> In-Reply-To: <20240822-arm64-gcs-v11-0-41b81947ecb5@kernel.org> To: Catalin Marinas , Will Deacon , Jonathan Corbet , Andrew Morton , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Arnd Bergmann , Oleg Nesterov , Eric Biederman , Shuah Khan , "Rick P. Edgecombe" , Deepak Gupta , Ard Biesheuvel , Szabolcs Nagy , Kees Cook Cc: "H.J. Lu" , Paul Walmsley , Palmer Dabbelt , Albert Ou , Florian Weimer , Christian Brauner , Thiago Jung Bauermann , Ross Burton , Yury Khrustalev , Wilco Dijkstra , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, Mark Brown X-Mailer: b4 0.15-dev-37811 X-Developer-Signature: v=1; a=openpgp-sha256; l=3111; i=broonie@kernel.org; h=from:subject:message-id; bh=kXO2GCPjz2S4M/TO1zkwKAs7nkqAlyHosyHP175ZITc=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBmxpE1uApeg/OZxbiMhFHBoLLG5SrajXWXBeA40vR0 FCpWfjaJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZsaRNQAKCRAk1otyXVSH0HXKB/ 0dMGFWwbkX4Z9sEwfB0dY/XOaKUlKCCMaPAx1bkgitG6AntCY2Kli+mJ2dVrlsJiiUuOtKpgm2upC/ gAkHa6Qz6FCwyehhZGr3MKK51DmUkjlCYkZv42cAn0qdft6eCTceFbLwHpGhfbtmuoHLWsvBemKz7g bquAPwNz1oLJQtKSHYXnuCFVboTAJ45j7tCfsXIAEQvBKAcKyxt4CZ6uf3R0H1+X+B8Rj9VhKP30tb QvinvkgvrTuEsazsCcV6TDz6yGerenIMpfRa2ff/BSMxGJGaws6R1VIaoOepqTODXo2vjVoavLksF/ dZQVmPYzpTvliSCTAB846/Xjk3IcAK X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240821_182045_892153_B3A09B41 X-CRM114-Status: GOOD ( 18.45 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org As discussed extensively in the changelog for the addition of this syscall on x86 ("x86/shstk: Introduce map_shadow_stack syscall") the existing mmap() and madvise() syscalls do not map entirely well onto the security requirements for guarded control stacks since they lead to windows where memory is allocated but not yet protected or stacks which are not properly and safely initialised. Instead a new syscall map_shadow_stack() has been defined which allocates and initialises a shadow stack page. Implement this for arm64. Two flags are provided, allowing applications to request that the stack be initialised with a valid cap token at the top of the stack and optionally also an end of stack marker above that. We support requesting an end of stack marker alone but since this is a NULL pointer it is indistinguishable from not initialising anything by itself. Reviewed-by: Thiago Jung Bauermann Reviewed-by: Catalin Marinas Signed-off-by: Mark Brown --- arch/arm64/mm/gcs.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) diff --git a/arch/arm64/mm/gcs.c b/arch/arm64/mm/gcs.c index 5eb746fdd872..d9614900c910 100644 --- a/arch/arm64/mm/gcs.c +++ b/arch/arm64/mm/gcs.c @@ -67,6 +67,70 @@ unsigned long gcs_alloc_thread_stack(struct task_struct *tsk, return addr; } +SYSCALL_DEFINE3(map_shadow_stack, unsigned long, addr, unsigned long, size, unsigned int, flags) +{ + unsigned long alloc_size; + unsigned long __user *cap_ptr; + unsigned long cap_val; + int ret = 0; + int cap_offset; + + if (!system_supports_gcs()) + return -EOPNOTSUPP; + + if (flags & ~(SHADOW_STACK_SET_TOKEN | SHADOW_STACK_SET_MARKER)) + return -EINVAL; + + if (!PAGE_ALIGNED(addr)) + return -EINVAL; + + if (size == 8 || !IS_ALIGNED(size, 8)) + return -EINVAL; + + /* + * An overflow would result in attempting to write the restore token + * to the wrong location. Not catastrophic, but just return the right + * error code and block it. + */ + alloc_size = PAGE_ALIGN(size); + if (alloc_size < size) + return -EOVERFLOW; + + addr = alloc_gcs(addr, alloc_size); + if (IS_ERR_VALUE(addr)) + return addr; + + /* + * Put a cap token at the end of the allocated region so it + * can be switched to. + */ + if (flags & SHADOW_STACK_SET_TOKEN) { + /* Leave an extra empty frame as a top of stack marker? */ + if (flags & SHADOW_STACK_SET_MARKER) + cap_offset = 2; + else + cap_offset = 1; + + cap_ptr = (unsigned long __user *)(addr + size - + (cap_offset * sizeof(unsigned long))); + cap_val = GCS_CAP(cap_ptr); + + put_user_gcs(cap_val, cap_ptr, &ret); + if (ret != 0) { + vm_munmap(addr, size); + return -EFAULT; + } + + /* + * Ensure the new cap is ordered before standard + * memory accesses to the same location. + */ + gcsb_dsync(); + } + + return addr; +} + /* * Apply the GCS mode configured for the specified task to the * hardware.