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 D9CFAC28B2F for ; Fri, 14 Mar 2025 08:30:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3CB4A280002; Fri, 14 Mar 2025 04:30:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 37C17280001; Fri, 14 Mar 2025 04:30:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F5A2280002; Fri, 14 Mar 2025 04:30:16 -0400 (EDT) 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 F3658280001 for ; Fri, 14 Mar 2025 04:30:15 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id EAFE3140C2A for ; Fri, 14 Mar 2025 08:30:15 +0000 (UTC) X-FDA: 83219484390.25.4BB7B33 Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) by imf07.hostedemail.com (Postfix) with ESMTP id 11B7140019 for ; Fri, 14 Mar 2025 08:30:13 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=sifive.com header.s=google header.b=lOTiLwNn; dmarc=pass (policy=reject) header.from=sifive.com; spf=pass (imf07.hostedemail.com: domain of zong.li@sifive.com designates 209.85.166.54 as permitted sender) smtp.mailfrom=zong.li@sifive.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741941014; a=rsa-sha256; cv=none; b=frjjg75qdHQE1PsDh5flrTnLPv78UEQDlv7DDYSzIv6uiYXnDIjTc9L51KwqxQn7uvPeNe qY8Y8ElPuckwKC7tbJecJzF3aH75l2xCKfpAPl//rlApy40ZkWoECbl7JixDRujOri1uBW R0P1LoV9GYJLYjyZr4YUoW2IwTnynTw= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=sifive.com header.s=google header.b=lOTiLwNn; dmarc=pass (policy=reject) header.from=sifive.com; spf=pass (imf07.hostedemail.com: domain of zong.li@sifive.com designates 209.85.166.54 as permitted sender) smtp.mailfrom=zong.li@sifive.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741941014; 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=JHQAFT19Zq6akViEkHfz6Mh4tV3mef9iqXwpMSCN/RQ=; b=1zxmVt/SIjqr7ozPFXSVc42i/iy95oLKW7WSWBXsJs8/cUJtTRHY/C/EdWGQrZ06LXSrWR RSu3QitdqfBNQBkQsZHk64L+5lFj7Y8vxVF7wptPknx2jwdcJrbTwhI9pGHxJJIuXelq1F //IpfDsuIAStXlu+w2XX3YdimnPBxSs= Received: by mail-io1-f54.google.com with SMTP id ca18e2360f4ac-8553e7d9459so43771239f.2 for ; Fri, 14 Mar 2025 01:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1741941013; x=1742545813; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=JHQAFT19Zq6akViEkHfz6Mh4tV3mef9iqXwpMSCN/RQ=; b=lOTiLwNnot2GTMApQgji3CUEFY1jFXVILXU+7YIZuvVKOZ38+jPgcBu5GbOOu8gvRs H9182nXDsdZQWzFUmVcigiGh7t8BYHudvz2szBESNJO/Qncn0CPpq5hYsynvokDpL187 3kPMtENITaxk++VC45b3bTc5F0sRbCPVemKDOBSqmJ/OO8j1wUwiBpsl6fw0nlZc3VNf xOw9QJxHMU/ofDYIRA0ZsbS8ssUicWGWYtTZSVt9d8IFJUIx16L3t6VdINl1L8NQFNRS e5Sq9dxAqDFbfn+hiU09UZCT1I6qJXiAbYFOVr7luIeIfZ0DhCwlWTdk/R2g92jvC3Vx dWAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741941013; x=1742545813; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JHQAFT19Zq6akViEkHfz6Mh4tV3mef9iqXwpMSCN/RQ=; b=W8i7arn+bzsvfAlP74tnI1quW8GdK5/yS8FO6ZgJd/l7U/Y5ULGLPYU0ypUEh26Vne M1i6mMlkfUgI3snVSLMqB5K+euiLJ/LnxwCSxQnFauFGyl5O3Lj8TIOtRdxCnpE/YKxZ ZfuMJopf9SLJFVSDI0S2dsrR/1A+1dSkW+pAjtT3XzsMdmlR2kMEm2OQPoHEELQOmyhy LInQdRADaNfGaDNC3QE7f9J8AkLlse2YOfG3As4Nd4QiZtgZHBXxtTnprcb/np6iBAyY a0nuVnTwsVTO53q3HJEd7xHFYnm0/lerr18dmZ4jBBPyfsMi38j9Ks1pD5H+ciHbsNLu iL2A== X-Forwarded-Encrypted: i=1; AJvYcCXZ3FW7P5N7dINr3iGMfkwYUJTyqV2lLm8nFNTo5eM0fXv14cXWP6/RMriXIAGw63y1gxKmfT00Zw==@kvack.org X-Gm-Message-State: AOJu0Yx7hKPdkh8aEHgW5tuFjYdfTG5McSgIJlZ+HQdvvtFvNKcJN/pY b5cSm+YoAfwGNM2Fx8KCWIZ0MkOoNyKu8QiQIUYOAF2C0r2cV0UsM/wZKeHjKzXRcqiIjYxpGel 3CjjvmDMGwy6HBvCCVv/2t++wgA5NjWah72Rqbg== X-Gm-Gg: ASbGncte47T70ODAIWXVHDVCH1CimKjJiA2Qm9uJD0pCXhaigRdfXEU7cOAmodsdm9b 8MMqFU5WiZ5ueLO9U9l3rRJQQmRSBjkQase8in2rJ/vELefLDlbDlkVfywKEzXLqwzqkzsHuyZZ rBTRryQr3L/M1eNq5Fk1HxvHurqYVzniyUFFjWuQ== X-Google-Smtp-Source: AGHT+IEQZBAAWQBzkkxA4UVWoIwfMxv3lOX1yAW82xZYAmzoSJt5ME/GJlXO4+fh8gCNW8gq2XMNfQJFOUPdwSXIT8w= X-Received: by 2002:a05:6602:4a03:b0:85b:4484:182c with SMTP id ca18e2360f4ac-85dc4885acbmr152534039f.11.1741941013056; Fri, 14 Mar 2025 01:30:13 -0700 (PDT) MIME-Version: 1.0 References: <20250310-v5_user_cfi_series-v11-0-86b36cbfb910@rivosinc.com> <20250310-v5_user_cfi_series-v11-10-86b36cbfb910@rivosinc.com> In-Reply-To: <20250310-v5_user_cfi_series-v11-10-86b36cbfb910@rivosinc.com> From: Zong Li Date: Fri, 14 Mar 2025 16:30:02 +0800 X-Gm-Features: AQ5f1JoD01TEQdI5WTe4PSnTnl_zETty75cDetOqvifwsUixI3qGOMOegGkUt3E Message-ID: Subject: Re: [PATCH v11 10/27] riscv/mm: Implement map_shadow_stack() syscall To: Deepak Gupta 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 59fstabbic6u3e6e949zwrwyz71egnat X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 11B7140019 X-Rspam-User: X-HE-Tag: 1741941013-774304 X-HE-Meta: U2FsdGVkX1+/j0ZQ9Utqor5SqEVs3KGRr6dLYlu4EmboRzhC13cBZtgybbHwE1Nuaf7huM12P7bnddUxTglGOA9OT5Kt33o/3kRUl6LsZqEk+btLwT8vHDcIKOrJodhmGETrwHPW+6jKYV4PJB38AK5QmeJ6vm5BgkcvOWSFjg7hDHmX/2+TLpRgkoFNqTwT75WbcI0GaIv9iHA06zv5/LYTuD//9mgDQNXPZbETlA9JTAQvmEvbm/uWjYlim0Gk7h5KgISwgBhz6hbUF1LTQV9oEDSBjGS20u+IqqIkfJ3kVyucjf+3b26zsOhKJJtufNM9Mp+t2HrxD2Nz/5r1RpYRMd7NCjQdOAt/f1Nr8O8UDjzaHkLEoh21Er0gVOFArnFsI3eWsOswvamc+WVCkF2YZtMJxgUiH+AmObPTRJ4xyUPC9BTbpvwcJW+5k+3OwKARvKqXPAnhTLQm/IC8Af7eEbISWj31Z0d3Js7R8ZGlPJkocOezs7f/wTWTGoV6+dUe15/ZiNIrkxfvjZ/rTrKhCjmnT4LD3pvXc4tICAaB/k4DgWNd1lEaw2C3oiHO1br23ITqoi/atuS7BpX+geHZzlx/YZ72BSQesD9I4vVxWyzqSW3uOrQRFEcvYt+bSZGM3IXbX2UKjtJIqzdWkTr04Xzz/QpQ/Qsrz0u5DcHFbNUGIC3IxY240TLAdyFXV7JCMODyVVZe/d1BaNUs0cz3lldzK/dOgofLpK9Z076JZxBIIAevpEiLUXp9koXwzsraU+5OnfrpjUCPAZSmLTovBVnyPc1l+ETK6bqXreGVf5uq5AKQWrKKjttHGlhLyhikHgeNo0ZLfzoWGmfsC8qcFPtPw6oBGsFADzyyStkcUMtYu0Wv/LEMnE+99gOmH7JGeY8xMw40e58u8lfnXTmiyxruxE4I4onUQoondDGKeeFUVqOMUo21DioM4vQEFKgObq1R6uj10GlkVYx w/l8ro3L XwPRUEFs2QgTYUrBUjMldibB8SGJ5c4PNNRgDvExUCwRiNlQ816aEwv4rsCx0VOuMVwPAsD5RwwUU0zBhSAhiPLn7eJCzieW5ATrGYpZv2EhV7+RpvBKQK5R/aRF1hkZuRy9YIh7Dot5Mgfg/7uNXXsKx+Z5S44kAl+2KCMLyvcGw0yOwzTQcJ8YNB9vunPPpu4z9dfKwsna7KF/YXZNm+Fl+4HS+AgxG1NwpXEJ4j8KW+nLLU71bqCTH2wDqe4jGQ4S4AWngblQYojs6FI8htLp8qxD80ctYKo09Rg0vd2aXBqPhGJkmrKSZ70IwccTopy2sN1MWdW/cjogL7Z5ZZgvMaqbCjxpGcPwhn+o9xJADve5x8exAAOCoOUUvrqGl5d1/dTTQ5Rc61RaRcXQ/fZ2KXFtjKPYCOdfSLQ37iO96KWxTCjvKnGtUbwr7Pb1/JItuP3XON6DxXRJiA1fT4jydhpBV8sF8W17lxG/KMCVES1I= 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 Mon, Mar 10, 2025 at 11:42=E2=80=AFPM Deepak Gupta = wrote: > > 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 shadow stack memory 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. > > This patch implements this syscall for riscv. riscv doesn't require token > to be setup by kernel because user mode can do that by itself. However to > provide compatibility and portability with other architectues, user mode > can specify token set flag. > > Signed-off-by: Deepak Gupta > --- > arch/riscv/kernel/Makefile | 1 + > arch/riscv/kernel/usercfi.c | 144 ++++++++++++++++++++++++++++++++++++++= ++++++ > 2 files changed, 145 insertions(+) > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile > index 8d186bfced45..3a861d320654 100644 > --- a/arch/riscv/kernel/Makefile > +++ b/arch/riscv/kernel/Makefile > @@ -125,3 +125,4 @@ obj-$(CONFIG_ACPI) +=3D acpi.o > obj-$(CONFIG_ACPI_NUMA) +=3D acpi_numa.o > > obj-$(CONFIG_GENERIC_CPU_VULNERABILITIES) +=3D bugs.o > +obj-$(CONFIG_RISCV_USER_CFI) +=3D usercfi.o > diff --git a/arch/riscv/kernel/usercfi.c b/arch/riscv/kernel/usercfi.c > new file mode 100644 > index 000000000000..24022809a7b5 > --- /dev/null > +++ b/arch/riscv/kernel/usercfi.c > @@ -0,0 +1,144 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2024 Rivos, Inc. > + * Deepak Gupta > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define SHSTK_ENTRY_SIZE sizeof(void *) > + > +/* > + * 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 > + * shadow stack. To keep it simple, we plan to use `ssamoswap` to perfor= m writes on shadow > + * stack. > + */ > +static noinline unsigned long amo_user_shstk(unsigned long *addr, unsign= ed long val) > +{ > + /* > + * Never expect -1 on shadow stack. Expect return addresses and z= ero > + */ > + unsigned long swap =3D -1; > + > + __enable_user_access(); > + asm goto( > + ".option push\n" > + ".option arch, +zicfiss\n" > + "1: ssamoswap.d %[swap], %[val], %[addr]\n" > + _ASM_EXTABLE(1b, %l[fault]) > + RISCV_ACQUIRE_BARRIER > + ".option pop\n" > + : [swap] "=3Dr" (swap), [addr] "+A" (*addr) > + : [val] "r" (val) > + : "memory" > + : fault > + ); > + __disable_user_access(); > + return swap; > +fault: > + __disable_user_access(); > + return -1; > +} > + > +/* > + * Create a restore token on the shadow stack. A token is always XLEN w= ide > + * and aligned to XLEN. > + */ > +static int create_rstor_token(unsigned long ssp, unsigned long *token_ad= dr) > +{ > + unsigned long addr; > + > + /* Token must be aligned */ > + if (!IS_ALIGNED(ssp, SHSTK_ENTRY_SIZE)) > + return -EINVAL; > + > + /* On RISC-V we're constructing token to be function of address i= tself */ > + addr =3D ssp - SHSTK_ENTRY_SIZE; > + > + if (amo_user_shstk((unsigned long __user *)addr, (unsigned long)s= sp) =3D=3D -1) > + return -EFAULT; > + > + if (token_addr) > + *token_addr =3D addr; > + > + return 0; > +} > + > +static unsigned long allocate_shadow_stack(unsigned long addr, unsigned = long size, > + unsigned long token_offset, bo= ol set_tok) > +{ > + int flags =3D MAP_ANONYMOUS | MAP_PRIVATE; > + struct mm_struct *mm =3D current->mm; > + unsigned long populate, tok_loc =3D 0; > + > + if (addr) > + flags |=3D MAP_FIXED_NOREPLACE; > + > + mmap_write_lock(mm); > + addr =3D do_mmap(NULL, addr, size, PROT_READ, flags, > + VM_SHADOW_STACK | VM_WRITE, 0, &populate, NULL); > + mmap_write_unlock(mm); > + > + if (!set_tok || IS_ERR_VALUE(addr)) > + goto out; > + > + if (create_rstor_token(addr + token_offset, &tok_loc)) { > + vm_munmap(addr, size); > + return -EINVAL; > + } > + > + addr =3D tok_loc; > + > +out: > + return addr; > +} > + > +SYSCALL_DEFINE3(map_shadow_stack, unsigned long, addr, unsigned long, si= ze, unsigned int, flags) > +{ > + bool set_tok =3D flags & SHADOW_STACK_SET_TOKEN; > + unsigned long aligned_size =3D 0; > + > + if (!cpu_supports_shadow_stack()) > + return -EOPNOTSUPP; > + > + /* Anything other than set token should result in invalid param *= / > + if (flags & ~SHADOW_STACK_SET_TOKEN) > + return -EINVAL; > + > + /* > + * Unlike other architectures, on RISC-V, SSP pointer is held in = CSR_SSP and is available > + * CSR in all modes. CSR accesses are performed using 12bit index= programmed in instruction > + * itself. This provides static property on register programming = and writes to CSR can't > + * be unintentional from programmer's perspective. As long as pro= grammer has guarded areas > + * which perform writes to CSR_SSP properly, shadow stack pivotin= g is not possible. Since > + * CSR_SSP is writeable by user mode, it itself can setup a shado= w stack token subsequent > + * to allocation. Although in order to provide portablity with ot= her architecture (because > + * `map_shadow_stack` is arch agnostic syscall), RISC-V will foll= ow expectation of a token > + * flag in flags and if provided in flags, setup a token at the b= ase. > + */ > + > + /* If there isn't space for a token */ > + if (set_tok && size < SHSTK_ENTRY_SIZE) > + return -ENOSPC; > + > + if (addr && (addr & (PAGE_SIZE - 1))) > + return -EINVAL; > + > + aligned_size =3D PAGE_ALIGN(size); > + if (aligned_size < size) > + return -EOVERFLOW; > + > + return allocate_shadow_stack(addr, aligned_size, size, set_tok); > +} > LGTM. Reviewed-by: Zong Li > -- > 2.34.1 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv