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 6198BC36010 for ; Mon, 7 Apr 2025 04:50:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 21CD56B0005; Mon, 7 Apr 2025 00:50:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1CBA86B0007; Mon, 7 Apr 2025 00:50:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01DC86B0008; Mon, 7 Apr 2025 00:50:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id D41DD6B0005 for ; Mon, 7 Apr 2025 00:50:49 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id AB657120BBA for ; Mon, 7 Apr 2025 04:50:49 +0000 (UTC) X-FDA: 83306022618.20.0C0C42A Received: from mail-io1-f51.google.com (mail-io1-f51.google.com [209.85.166.51]) by imf03.hostedemail.com (Postfix) with ESMTP id AFD2420006 for ; Mon, 7 Apr 2025 04:50:47 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=sifive.com header.s=google header.b=Dh9bzIef; spf=pass (imf03.hostedemail.com: domain of zong.li@sifive.com designates 209.85.166.51 as permitted sender) smtp.mailfrom=zong.li@sifive.com; dmarc=pass (policy=reject) header.from=sifive.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744001447; 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=CSbT54uFLuQxmkO99JJbKmBYJPhP8w1aIEAoXHHJX9k=; b=4AcNlkvuYRSC+Gaxn35kZpwQ+BOnCVhiNc1JZgsChhFxNpwvbGsaH2i8InF/E42iHG2/K4 yukoX6sh/vGaJ6eUx2zoXzZezzcri5RIFrqanNFOCTKYny+Eof6/heGHbVNn3cgNxL4A8h HZn126kh/9os9OV+jCNf1vZ3CrtpG0M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744001447; a=rsa-sha256; cv=none; b=dh8D+Nvmhmv4n7+5xmiZxuhtW9Q1iC4qfNFUgSXAm5nJzoAT2xnNsCr8+UNdhuwEHPHWoA HdPtETmOkXcxGUWIBRWhliR1mkpZzL1CupXDVlFK1FqSZni8lIZ7FwruYfuxdPfUIBqowZ 1EjCTG+oZ9uxMGRyZNpkU40BjUx/Rj4= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=sifive.com header.s=google header.b=Dh9bzIef; spf=pass (imf03.hostedemail.com: domain of zong.li@sifive.com designates 209.85.166.51 as permitted sender) smtp.mailfrom=zong.li@sifive.com; dmarc=pass (policy=reject) header.from=sifive.com Received: by mail-io1-f51.google.com with SMTP id ca18e2360f4ac-85b3f92c8dfso125920139f.2 for ; Sun, 06 Apr 2025 21:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1744001446; x=1744606246; 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=CSbT54uFLuQxmkO99JJbKmBYJPhP8w1aIEAoXHHJX9k=; b=Dh9bzIefgTxmoGYf+SGTf+BYIBX+noxBF24XanrkPjzNArv70qswKJz5KxP6oJZqDm SfMJ2XAUmnFTIqiYi3ac55goPgRza93OjlFEUfyIUxaFk1NGKpG1DBUjlGr9K3bG0axz frNmbVku7wh9PmH4Usg4v0zYmXZchYbSVHVWJsnYniRAwhFhdV6yT5yFT4II7fgUTWIq rxXWtqXUrIVEn+KNDcaSpW8NgzLCbqVkjYdT81aDHjVicm6q4UDYwLH7IQD30zXZXZwo b/f4yOxt0mpI071SzCUkoENJ5ZWf1mdl0bb+glZ+zSIBy4Vx8jTHwZHxnHmPjE92zjq0 9x+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744001446; x=1744606246; 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=CSbT54uFLuQxmkO99JJbKmBYJPhP8w1aIEAoXHHJX9k=; b=Bw7/ZF9HNGF7aExuH3clQ8WlIkQffqTJGHs5Gj5U81ki0GIswNkir9FQ8y6Zi7Alnf w4MJYbDG90XQirUhyit3ULY6R7spOhre2b5cwAi7Vc+eZkWhcI4xAT3pRQIPi/qmaBU7 g7Svq8FCz675UkbnALnUDhx327TyTRGKublEk6jsZFxSNf6u1VSuZt4EfCDxmOoAFCTD lKP2I7gqI+MqS3H1nNghlazwSbX4G9gQ17xKjHChtXnNvZ3+bIVOqECLKqv69wqpTE7l FV0vMM8Dkew3leO+vVG1mWD5X9EBOEo5nuzW1VCy6iglxuY0x0aWxO4hkW9pHBgbfIte R9cQ== X-Forwarded-Encrypted: i=1; AJvYcCUk4qMLBQvpeLPvHt5lkH7I6ghZvBNgJCDz9yqLd2ZGFgm18xYj3xSAE1IZMQ5+NA/gpq4UvFMXBQ==@kvack.org X-Gm-Message-State: AOJu0YwB80RFD0WxyY5GHlQi01dhfVXEoziL0tG3uICyuZtlzZyNJbPH QtuBUgoC49DudW+byQh0vFkvQR8vLBrLk/8UWeU1TGCO7FHt73cziIuITaQuQrT1Yanf0zTAwCM 99Tv47FCboOif6IRRrQ7cF3x5CQZ0MaG9z4fw0g== X-Gm-Gg: ASbGncvOPHewuB/k8JbJ6Yl++MLMvMIXfPUhhbm9NM2a9Nb66Oo5Wnnvei1UJj/EQii KEKlB9zi5JZ9dgKxaodkkUw0WDIMtn2YgyNXpocsLNvkSxjsZlkb6mUoZEOVdbaK2t81nD4h1rL duu5NfcbbZ7YUS05gfu1JcrcSc8D/F X-Google-Smtp-Source: AGHT+IHhVdalfJg/Z7eY6UsCfbBA0DkGD01gM9P/N23DqqMhnu+Yb+G3qK68lvaA0KDDPK6sloLhNYPOVe1kjlQCo1M= X-Received: by 2002:a05:6602:4009:b0:85e:201e:3e35 with SMTP id ca18e2360f4ac-8611c2a4dc8mr1200799239f.3.1744001446586; Sun, 06 Apr 2025 21:50:46 -0700 (PDT) MIME-Version: 1.0 References: <20250314-v5_user_cfi_series-v12-0-e51202b53138@rivosinc.com> <20250314-v5_user_cfi_series-v12-10-e51202b53138@rivosinc.com> In-Reply-To: <20250314-v5_user_cfi_series-v12-10-e51202b53138@rivosinc.com> From: Zong Li Date: Mon, 7 Apr 2025 12:50:35 +0800 X-Gm-Features: ATxdqUEcEvSvDd4YNmxt5x00v_2QFe_U7ZYW7BCOZdpLL6G50qHXNh2VbNcPJLM Message-ID: Subject: Re: [PATCH v12 10/28] 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-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: AFD2420006 X-Stat-Signature: 8j6kttoicnrjkr5s86847y5nyne7m7pw X-HE-Tag: 1744001447-26037 X-HE-Meta: U2FsdGVkX185eyMUA49xxS02dWLSSsjLla0WJxIiYoDMa/0oV2QgMyr0ViDt7xqeBRHP22STY2otbjqXrJbjazKxVBZiRwbnohq6Y0KFoCAJYmAaNORGL4vDeJfbIy8lFpfADJuLUFLFN/McSCnHupzUguZobHX9m+FdU2qKq0286dtJc7n+mPHynxvmWBr3wIWw2vZf+VgJF6qUBIhBLA2xMzS4qXjx+SZX4SJKgEloOoOIjLmLvQyI1sp89NlxtoJWSPGn9caecERNKRMHWOTLouLLbjBcZo0EPVKmTO9DDQZymPixuUuZCYH3luazWvvL9InqWnC57fp38Bel3K9Ws+NikVNhnb628UcqMWSvwXdMnm4LiUImt/bZHWfR8U4Ku9Z6Z54unKVZQ2WuvoMIu1nUZAWxTxJQagViMaESxVK2CzS0qI5cOIUR+Xwaswgv11nHIGOKzHcHCqReSUJjV2h/gsGH431HyBj/fSdB8P4JRIATwbzRwbjq2qN3ZmnI4AxQJPLd2K8GvHoV5EkkJq8Uagpsu1g96WR4gHcQSkwJgRfNAcWtsAr2krZqJcWfElOPYNMRbO/ZDLTprIMDoKawNeQnVDXGaMBbR7lTt/XzquTyyWA540rOU4NncothGNetdR84zmGAO2tumBxmhi67MeOdR+qAP1LRXULQCOdT6xVP/oHgDJ93m+jn3xqcPaF5qIeY/daPcQymEAKJxbxYK9X+ZE0B8+izxCsCWmOvhvI4QIU70tkxHum4GXmE6N/a0oLGxe8KjGW3J30ubw39dWGknWSWia/MUt/0EFVqGM2dL1QjsNNLQjxmyBtrB4rq6XuRIabbDKiOaC7xZNNmU845wsOq7Hen8DKP8Hqgm7Y7LvkWK0YHmUSJDJxffRXPMy57Wz21Ac75xQi6uAo17TwNHM2fNyLwE/nmX2QEbVZ3TgkNLsMKk6V3CUjvNpldYy6YYgJMek4 wzRy8ZMH YEE/XytOLvqyX0Q1CQV5cVZ08shHW0dMzr1GuVJn/BCbsc2RjyepGIQo6AQQ6dhGqOHisnBQ4C90ulig0MyjTkhoSh30kkXx5E3G+BSBRma/vtBu0a9Z32FYaDgZNsMrR1tR0lRPDeoycPTsqYf/ER7TwGzbCGsVQT32Qp5T6rjRQ9rI34+EDBGZRW1FghVNGH4XHVxsFxWJyGaK5XNfSykRMVOsVoLV1AtGPEwINLePhwzh+Ai6WNMBGgJIFJZ8gBjYQ5X06jm5H0BUhE6jXtwSfyNjr9nhjsFKMuJbYIRsZquq6MSa9kIQBAxCNzydQS8kSSUm4H+KEITGCFHf9gIxDFCcYlEhjCamIy5zImyGqv6fQD+HnSn9kiA8CrYxNoO1+R0H71H8bk3bTi/gurIU92XK/clL/PIcwJsIruV9bH4RP/Lrh6w//tg== 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 Sat, Mar 15, 2025 at 5:39=E2=80=AFAM Deepak Gupta w= rote: > > 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. > > Reviewed-by: Zong Li > 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" Hi Deepak, It just came to my mind, do we need to ensure that menvcfg.SSE is not zero before executing the ssamoswap instruction? Since ssamoswap is not encoded using MOP, I=E2=80=99m wondering if we should make sure that executing ssamoswap won=E2=80=99t accidentally trigger an illegal instructi= on exception. Thanks. > + _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); > +} > > -- > 2.34.1 >