From patchwork Sat Feb 3 12:25:48 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Brown X-Patchwork-Id: 13544147 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 E0704C4828F for ; Sat, 3 Feb 2024 12:32:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 65B8F6B00AB; Sat, 3 Feb 2024 07:32:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5E4776B00AD; Sat, 3 Feb 2024 07:32:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4855F6B00AE; Sat, 3 Feb 2024 07:32:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 387216B00AB for ; Sat, 3 Feb 2024 07:32:13 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0987F80841 for ; Sat, 3 Feb 2024 12:32:13 +0000 (UTC) X-FDA: 81750430146.26.F45409A Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf02.hostedemail.com (Postfix) with ESMTP id 3132680013 for ; Sat, 3 Feb 2024 12:32:10 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GKUG+zpZ; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf02.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706963531; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ndtQeCQ4TKXeYu1kwTWL2JKUP+nwERiDqFCxKHXGeto=; b=loasz3JGJTW4ap18V2scr//2iKADoROidRlXRdP7LB0CzER1x0x8MzXoT4YNkirz+YlxgN RhD4CNtvxN+y2o1WJvJ2Q2FDwz7pvXTXscX0DU6j2bHWQRfqE/mVDZcDIo1dkDm77tJpQi CM0E+Hknt1gByPFFBM3AiRoQxTZytlU= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GKUG+zpZ; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf02.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706963531; a=rsa-sha256; cv=none; b=tt+Fs8S2+uPUf2TNraTjbvLPk1o9RHSzaa/x++Ic8vGKGxyMBulg1TRJKoZMDCCwAZSpJ3 PJWaMQz+mSO4qF5Xell8pGOYa4NZaHnkpU+zyfbZBvx0+ppU0izplEDUcjkkzpKxdh8L+f SR3MubKO/BPWwMQAU3MgtCwSR9jvzeY= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 304996069B; Sat, 3 Feb 2024 12:32:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A16F9C433F1; Sat, 3 Feb 2024 12:32:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1706963529; bh=Aw31IGKjr1UrJDLWxkb2b/BK0n5+HbIF3Im1kdrhlF4=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=GKUG+zpZ2VILKpS5XDiWYdz2oomc5hvV3q397oN3cKwrqvjN8JKf9ZMOB+6zZRcY1 iTUhw186L7BkGkiyEnDwbA2D1HfTzsgjtdPEhb3OSGyDDEL4L3JlqFz1AWtIBAQSY6 9dm9WMbF7/+oCBcxK3fFKSGyTaH2t0ukjuHqcX8qIGbanmqsR109W7myEvSS2ptTye FSH1gSgaA3tm4tUie8cuI9rQF5s39SGkMpyheiPi+onw9b6y8icdbNSgLC+iGX/nJe CxyxwaJOf9c9pdGmuwR4iuMbniVufpOG9YnrXm3OemlI0rqHYkzLn2mzlr33eNnXwL 0mDazwlGIzVkQ== From: Mark Brown Date: Sat, 03 Feb 2024 12:25:48 +0000 Subject: [PATCH v8 22/38] arm64/mm: Implement map_shadow_stack() MIME-Version: 1.0 Message-Id: <20240203-arm64-gcs-v8-22-c9fec77673ef@kernel.org> References: <20240203-arm64-gcs-v8-0-c9fec77673ef@kernel.org> In-Reply-To: <20240203-arm64-gcs-v8-0-c9fec77673ef@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 , Kees Cook , Shuah Khan , "Rick P. Edgecombe" , Deepak Gupta , Ard Biesheuvel , Szabolcs Nagy Cc: "H.J. Lu" , Paul Walmsley , Palmer Dabbelt , Albert Ou , Florian Weimer , Christian Brauner , Thiago Jung Bauermann , 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.13-dev-a684c X-Developer-Signature: v=1; a=openpgp-sha256; l=2931; i=broonie@kernel.org; h=from:subject:message-id; bh=Aw31IGKjr1UrJDLWxkb2b/BK0n5+HbIF3Im1kdrhlF4=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBlvjDiF619KL+pXnFncRboG77ij7BrGr7OUVw8KD54 W94MjnmJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZb4w4gAKCRAk1otyXVSH0Jx+B/ 4v6RH+W/BD/bwrjhMex1EknsuooW4f/43TzROGdgQf5ZleIEHLx7aQHusweh6WwRiwnNYYsQ47/1EM BBeH8SXHb4LF1Foh1DTm5I9/a3wa3noh+LUCiGbbO1uvAOAcrsconNTQ4XfZmOTHEVomxOV9JdONTR mrghCkklix5q/XA7ublf7dKYPmkBrd4XpgT/S80mmzPh5YFsOt3wpu+UCpqeqcgyCacBE7C/v284GH zAJjljdn6oB0SlBacil3LPR+nO9vOcxZaN1lT2ae59T0BR5pE8p7S+qcMIYriIalD501OnOZhMaNTr rVijbRZWUs3jqHufM94IsGOg3p/jRe X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB X-Rspamd-Queue-Id: 3132680013 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: r4o6y7gmcpc6f4igido3aegsie4n38i5 X-HE-Tag: 1706963530-772844 X-HE-Meta: U2FsdGVkX19plEPXIfXU65lafnBlF094bxWYxGzqw4FBUKFeclvvRNYvRDsmuaoVbxOxCbw2EytMhzNr3f/lu0y65AYcL7gzASVzUQs+EbmGp7DyCGdt4tA51NCPjhMDNTNKekButALzVu9gZ4orD25qFwWjRBFPU/zKtGb3lCXEB8GEqV8tsPDNNRiDTTtJniFuc1iCNVI64RYH+CFCmraN0F4gXqc89AjgB9tP7qkiHSSkWeeGkqAuooUwcQuIchGSHJ9Lemt/ju56msAWyshPLMp6wtdxv9rjeaZ7Xn0+rp79NJ/ugLsDKm3swxCgE7dopcleMbYmIFRozDVyWmLWo09UYdxvmLnZ2kc7Zu58MKULvv1+kSGYrb7d72iP2Uh4pK5JUDD6UaShs7ROjtL8yUy2By+v9hyIRMZ8X2TOiZhpuYTwN4f51Ryz/XfTUiUMUbxxTueXUOdEm+ZciSBgyW01DEv6oqyfBeGHbrNd/Ng8XZ7WTKDgmhPr/I24TYG/QP/fKlPSGvAh8W5VVT4xFakTnP6hV6tDdK5nNzD5R0LdeEmiaCLVLmokq4QdOLRuHCmzpTFCcAzP3kSndNJQAgsdk5W2Vu3d/OlM29S9Q6D/PgPmtmt+2j+FtRSMHSA9SO8NCDuUhVmrwBgc0ObS6/D0m82OZm9ERTFPxfbnUx42QLAai3VLjcpji36W0CLIsxfCdAcFCSPFyDyf/Na9gD+s5iNrnflwwfidoZNMnLrYoPmSRS8kQGa/r+GqFgT+UwjcRNXJux4eCqON2O5B+zEOwDpVP6KnoL+UgMgmFesycLm6ILjrWRGnEr3HUmsYoZ6neTYQdk3yM4zc7P7J6Cje91HNKAMmgze+fSVRBwa0FJ1geE0yEPg5eekktjM37KB3O7ugwmcTipbBkgOQ/59KA04W/9GbfBZ3eCMHbW7KHbQrErxfOv9tMZdrq9XaoXsacGwBKyNq2Ay 4Dt1inTS FZ9LXHQRtNAUyp0o0xhp6YVBlUV24oet+mBWK7Qv5UeDJctr4pAL24AE9az2xpGeLBvDh/mhylkU3f4Yib0nYUQPSLyfOQOQjEehYto7gIV5+vu9hqgMAinC602ykL7ZPR/aJelrlVI15MtaUrcnVT5THJkq3PQQ/w7ePmkC/lurGO09xUewB8FD7k1pfzqo7cxwadBCi474BWKkxu+TsTeKtqIOTDlOWQo3SrLhltupr/oCQboolsXhn/HzYWaKPGos1UQIUuqLWEs5QH7iyI9Le+v15nmErWDgfU55xq9JaGlGN8ECyOI+6s5nRZlhb/AoWkD8Ofnm2enjX27E1m7k13TBnUdsrHrgdU+tzd4sN3NNFb4eAnFFNyw== 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: 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. Signed-off-by: Mark Brown --- arch/arm64/mm/gcs.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) diff --git a/arch/arm64/mm/gcs.c b/arch/arm64/mm/gcs.c index 95f5cf599bc6..f34821d98d85 100644 --- a/arch/arm64/mm/gcs.c +++ b/arch/arm64/mm/gcs.c @@ -115,6 +115,67 @@ 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 (addr && (addr % PAGE_SIZE)) + return -EINVAL; + + if (size == 8 || 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, 0, false); + 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 viaible for GCS */ + gcsb_dsync(); + } + + return addr; +} + /* * Apply the GCS mode configured for the specified task to the * hardware.