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 B9559C3601E for ; Thu, 10 Apr 2025 09:56:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BF0272800BA; Thu, 10 Apr 2025 05:56:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B7A312800B9; Thu, 10 Apr 2025 05:56:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A3F742800BA; Thu, 10 Apr 2025 05:56:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 85FA92800B9 for ; Thu, 10 Apr 2025 05:56:48 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 58B3A160155 for ; Thu, 10 Apr 2025 09:56:49 +0000 (UTC) X-FDA: 83317680138.07.E61BC49 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by imf02.hostedemail.com (Postfix) with ESMTP id 607698000A for ; Thu, 10 Apr 2025 09:56:47 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=ventanamicro.com header.s=google header.b="MA3Zk/fZ"; spf=pass (imf02.hostedemail.com: domain of rkrcmar@ventanamicro.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=rkrcmar@ventanamicro.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744279007; 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=0PsTek2iG0P9gXerP0u/dhkc6G7oyliO6C0xZFmP/8A=; b=TWA+UKneJZPJL0MikzEtA2CxEfU28X5LNVMjEOQlDJvdfBZm8gKJr4dtX464bt9z3NBwK4 MgCaaNkeVUBl7xbY+QPFGgTnJlmIQQWu7rN1xyZvMNM9UVILudxx+L/TG+FswmkRrhDd3C 8jzBpQW8I85Pcg4/rktfYEJ8+cr+w+w= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=ventanamicro.com header.s=google header.b="MA3Zk/fZ"; spf=pass (imf02.hostedemail.com: domain of rkrcmar@ventanamicro.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=rkrcmar@ventanamicro.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744279007; a=rsa-sha256; cv=none; b=47muhmkiG2dohma0h8FvntwJ8ysT/E1qY3IF04pc9v1hsbqJWdP94SynGA7HUH9wMYOgAD hH+YpFhVX+HY4mFuo0xFy0ZNQSw84fnnhhLp4YZz5IbMwOSSgEnTJ4cIN2UyRGRSYOlK+9 N7eH8fm+dMuf6oXgHO3aJQ0iaqJWO2o= Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-43e9ccaa1ebso670775e9.1 for ; Thu, 10 Apr 2025 02:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1744279006; x=1744883806; darn=kvack.org; h=in-reply-to:references:from:to:cc:subject:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=0PsTek2iG0P9gXerP0u/dhkc6G7oyliO6C0xZFmP/8A=; b=MA3Zk/fZVW0K3yt/Dtz0aIJiVG/j3wO/1GP8IKdTlLlQR0ioVgB1n2wf4zxFkV9mX3 iCHgoHkaxP8D5WzObgims6+jXxOVbvqALpmstmTMRNvzyGV0mgIFtUAWeN2P/nYrE9G1 viQsAWBzKAzPMk5Dg5AVhO0NdREQzt9bBJbjVcpeyseZ2SxUVzlaZiyekdTKvksZqsxL LTOjTeD7m6QaF4MQ1BDZZxCTkqSPAsfV0U+s6JZXcbkRyJQGZ4s+QqKTVZhSQZKLOITC vzhp9IC7w+hRRQY6umPjEFbD83CGJuRvZcFhsVZqoxghafprPCXJgEBaYLTUh67Hqx1q t2Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744279006; x=1744883806; h=in-reply-to:references:from:to:cc:subject:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=0PsTek2iG0P9gXerP0u/dhkc6G7oyliO6C0xZFmP/8A=; b=mwgHpwDAwBnBTwEJTb4rp5/wSRStMeqhQX8JrS2ImrFFj9tYhn21zJacc10FtXZdCW baY95ip4PwdHjCxIKnnpfrVhB0d60RQdjxng9IQgfY/PyumwcDpZm1R2VM/AV/ExSjbk rOxzCCyJaNq5+c2n3dpa65tTokBUbKPRjHYXqY08L7gYULcMl4FlvtHm38+gmOWp0iXc BO7VGRebo/43mhDtLgwSFr4bVFd7vcOMqwr662kKktNyt8Z8MQ94A5jaH0DXR/lKkUDp lOuauTY2SQTg2YEQxkxn3z3b9VtnJpr+VaS89OZPS1U0/gV0OWlITEVQVtBNNqwVOC1i ySJw== X-Forwarded-Encrypted: i=1; AJvYcCWRYL85XUfCBI0sOwwGNX22xLNM81vq9uoEfXoZCBZZEQf2/dTqFiukysfM8fDaeMefqQyYdDkX0Q==@kvack.org X-Gm-Message-State: AOJu0YyKliTesrsuVCdYXfj0F6xYs39rjL34jWO9njOlrNRwqz2diV94 HB59mtCbAKYe8sjdSYABVith+tX945l91PLmVqw+nMtAvVAKJBNMzdCCroc3DJk= X-Gm-Gg: ASbGncvhXmp/EhsnYbZw5iJaIG+YVYXq7oNxyHCwku+iiSnxoU0rTQEHhcP5PMOztDk WXLRAchz+Z+r1KdOXZAvcJ36XaNEHkYrSTteDmvMBMlJ62VNfzIAfP/XqPbIaNAxZt9N1mCpyil 68lGaEECasrJsR011I5S+92sJ1N7dEFWYqwJBj8JkkFC4Ei6tSrd2+ZRLH8Z2IFXaqFfrdKuMCY /g4d269q2JLKKKnzRSMWvfxK0JXrbMrbIHsH0wuU6rrJksCu0JDgdgu5fMR7UyUP2sfFtulJ+xf lTseOK81uISCrWu0A/hnEOIeXb/1yeXtP6V3fWRjnmnc0FGd X-Google-Smtp-Source: AGHT+IHBsekVmgMMcd9frJRGybN0tNs9jfPFgV6X7l6TgORlz7EkCuYcLx9G1wBU1KIlE1VBTkos1Q== X-Received: by 2002:a5d:6d8a:0:b0:39b:f12c:3862 with SMTP id ffacd0b85a97d-39d87aa7badmr2003379f8f.2.1744279005675; Thu, 10 Apr 2025 02:56:45 -0700 (PDT) Received: from localhost ([2a02:8308:a00c:e200:7d22:13bb:e539:15ee]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-39d89362fd6sm4349691f8f.16.2025.04.10.02.56.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Apr 2025 02:56:45 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 10 Apr 2025 11:56:44 +0200 Message-Id: Subject: Re: [PATCH v12 10/28] riscv/mm: Implement map_shadow_stack() syscall Cc: , , , , , , , , , , , , , , , , , , , , , "Zong Li" , "linux-riscv" To: "Deepak Gupta" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "Dave Hansen" , , "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" From: =?utf-8?q?Radim_Kr=C4=8Dm=C3=A1=C5=99?= 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> X-Rspamd-Queue-Id: 607698000A X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: jwn5tjibtrogf4f17zs6o9wsmmns6566 X-HE-Tag: 1744279007-910875 X-HE-Meta: U2FsdGVkX1/0bOQ87x1/ts16TyHKdXBdaJq0rHEAlFf9oLkDyoX67uz91P1v6Cn19ny8LwD549BomL5AeHaGagZp9rgSoFSnZjDoNaNzsRKVKF18pRfBrbyeJ2FM3hLuEc1+Ox2IlDK7JF8SMp48jAtXsBhr7vv8B5vr73IdEZkrP8AS22bF/DaA2Zqd9IWz37H90prBzFPidwCfHn4bR9fTPUaV27iIqSAiH8n6RddML0bAXhIyIHEbwRThd8rKO0M57kob8ymn/XOFzkUnwk+1Klv/02wkYJ7Gde/lNq2tj9Ik9f1NvJ1Ai+T5E4s3gyxgkPocSSh9t8rnXlzRWA31xrgr/yx2LG3TP76imRN4ayf6eDw5Oz/J6m6CqjyoLRpzzgmahsJjM5ggw2M+yjcmfGll8mETx0zFRi/Clmqx5ooCNl+75a5sFUhDD2mzPdFsBYAgE8AY9WT2KDlSXEWsxq6wkPG8GgUrCIQX2L91IBBkbfgEiCm4ESEf+qWGTm7ajukoSPQl6C+gwV/+Wy7nKuR9MnWG2MUfi3u9jIWPpxVcpToWgSPPE5KM0yehEK+kuNr3au9CcntMOrIj7kWkhInWSSTgX60aAU4ETHUDM6CGLb6lRElOO2g3b3PR9KHE6kdwG3XxLMIUEA42MqpjkIvapSCIFKHzsUj5ZwkTFbSmh3E3Quv8KZdpz6TgYM6EGvDZ0BE4TK7gU4h6sWcy5qDzBIaseg7m+OaG+Z/9bZofjgKe6zkEkhVm/kLRTLqwYOudAYCKOvUccoBGu1NZiQ6+uwWDd+Wf7MUYbssaQTS5NXaLHYKTFlsk9UeqPh3eH5eJ1s/soVxS99FPoM3gK5HH+70/Hob7LAg3+7dmaa2iWWL6JdWPWO8mT+0Mn8mjPbvaSP3fArkWFiNkVwKk0VUoEstdetc30TQoc6i9taDK2ahhU73zd3PBv2+eyECF0WCehVGpj8H20cf wMsw3saE jqV0nilPFI8xUnxeAjsIrOTTj1H37vidvuT227TrsnG9MfcyFz5SYAfLkdOF9yBzPRD/7WbhLD6a9/XG4BYMaN2TgpDKBUATJn0y0qvf7rX6G2hJ/mu38Xod1GY3b1f1cXtPurLSGp7jsD/PI31L+g3Vf9P8nLmMJ+SY8pbwTP6jPieU3KcAjZ6zUZTbM9LMljrYlISZUzrAsbUjl3BLnfrR/m3qCdF5CNDhq8zqbebRzxJUYTi9wm9c57LJ5GTUqzoqHxSn4NQIjB9d7WheqUCUsQ/GvVkUDxM8d19oydrkQqoaUpwajQYOqx3TO/XlLxo2sy9vTyv08KDA7pjMPN/QM/nkCIEzWhi6nEy0i7fROm7Mq2B12+z3ZtJPiinpxTPl0AGyu8UnWZhQn0uXaKFb5uDCBvhUIXJ5vwe03yDedAxp7AdRmHPL5AZpunXTFjyp4iITqhu2nQq6jgS7O/3/TjcgM9+3F5pIOhUyB0vhTds3c853kv2wtO4WQjCF8GiIphoVmyTtgmfrsMzYwiZLDefb6IMFOqjlPE91yW0lm++52dlAczT+ul2yhJCiLlniOelIzhoVKB7Aollzarxqti17VujfCQUGTcJF7p6mxLjnfm6UzSEp3IM8p83g8fn8ifxdHgDCFIgXdI8TriwTf5RVzRM68VnOPrxzEDtvu1/kqIFEJoAu/gAvKjAbk8po2clAkmbDaBRWF2pTyz7mPIlc/8DNHSV4B532RqS/89BU= 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: 2025-03-14T14:39:29-07:00, Deepak Gupta : > 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. RISC-V shadow stack could use mmap() and madvise() perfectly well. Userspace can always initialize the shadow stack properly and the shadow stack memory is never protected from other malicious threads. I think that the compatibility argument is reasonable. We'd need to modify the other syscalls to allow a write-only mapping anyway. > diff --git a/arch/riscv/kernel/usercfi.c b/arch/riscv/kernel/usercfi.c > +static noinline unsigned long amo_user_shstk(unsigned long *addr, unsign= ed long val) > +{ > + /* > + * Never expect -1 on shadow stack. Expect return addresses and zero > + */ > + unsigned long swap =3D -1; > + __enable_user_access(); > + asm goto( > + ".option push\n" > + ".option arch, +zicfiss\n" Shouldn't compiler accept ssamoswap.d opcode even without zicfiss arch? > + "1: ssamoswap.d %[swap], %[val], %[addr]\n" > + _ASM_EXTABLE(1b, %l[fault]) > + RISCV_ACQUIRE_BARRIER Why is the barrier here? > + ".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; I think we should return 0 and -EFAULT. We can ignore the swapped value, or return it through a pointer. > +} > + > +static unsigned long allocate_shadow_stack(unsigned long addr, unsigned = long size, > + unsigned long token_offset, bool set_tok) > +{ > + int flags =3D MAP_ANONYMOUS | MAP_PRIVATE; Is MAP_GROWSDOWN pointless? > + 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, PROT_READ implies VM_READ, so won't this select PAGE_COPY in the protection_map instead of PAGE_SHADOWSTACK? Wouldn't avoiding VM_READ also allow us to get rid of the ugly hack in pte_mkwrite? (VM_WRITE would naturally select the right XWR flags.) > + VM_SHADOW_STACK | VM_WRITE, 0, &populate, NULL); > + mmap_write_unlock(mm); > + > +SYSCALL_DEFINE3(map_shadow_stack, unsigned long, addr, unsigned long, si= ze, unsigned int, flags) > +{ > [...] > + if (addr && (addr & (PAGE_SIZE - 1))) if (!PAGE_ALIGNED(addr))