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 8F0E2C36002 for ; Thu, 20 Mar 2025 22:43:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 31FE3280002; Thu, 20 Mar 2025 18:43:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D084280001; Thu, 20 Mar 2025 18:43:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17207280002; Thu, 20 Mar 2025 18:43:01 -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 EEA97280001 for ; Thu, 20 Mar 2025 18:43:00 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 4BFFA1212DC for ; Thu, 20 Mar 2025 22:43:01 +0000 (UTC) X-FDA: 83243406162.11.05373A0 Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) by imf25.hostedemail.com (Postfix) with ESMTP id 6F299A0011 for ; Thu, 20 Mar 2025 22:42:59 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=d9WJy2pS; spf=pass (imf25.hostedemail.com: domain of debug@rivosinc.com designates 209.85.128.177 as permitted sender) smtp.mailfrom=debug@rivosinc.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742510579; 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=Qn+4G/BZfte1kQZajpdgC3z6H+wA6NVBYYf22eoImB8=; b=A/0jK1D25ORFFQ6FQGIOq2nemkiKNt7uwK9cvQ+BYGab5sWwryQ66mN7FMlH8Q0kmGsL/o iOxQ5ipiXVpVOQjxXjRcF6uf6+9iBir3VTo/h7Iy+fQ+QtJAymeIFVvk6HI7jgDvC+Ho3E t7a4T4L3PG/p3yC/wwDth4ljwhRww94= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=d9WJy2pS; spf=pass (imf25.hostedemail.com: domain of debug@rivosinc.com designates 209.85.128.177 as permitted sender) smtp.mailfrom=debug@rivosinc.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742510579; a=rsa-sha256; cv=none; b=XoMQTl7pbDBs8sV6GHnQusogtasCcZ3LydCa2NhQe+XldzkzCRDAuGph26sKek/BbdTetB UPvv5uHA2hEVKIBt/H0KKG+WkEXeUffYg/Kt+xWpF2csPPLqDJaKY02uRssmh4FHiMTbrx NYe5I/lhq5fndAfNCRswy70/nB0hK8I= Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-6f7031ea11cso15100197b3.2 for ; Thu, 20 Mar 2025 15:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1742510578; x=1743115378; 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=Qn+4G/BZfte1kQZajpdgC3z6H+wA6NVBYYf22eoImB8=; b=d9WJy2pSQTnVnaa4e7++QtKs1HjS8+DABnmLbZDPi3I4R//qHZeiQiXjuJAhzuxvXx oM1RUZnKUw2gt7HVXlCT9jxmpCD4Ul/UrsW64H2xMQvHY1aIAo3O40wcIRe0NbBX5pD6 zSVo1Ih8/+RFEx+oDIlPERwA0UOF8jwsGDSePAqDJkftU2gEVhpJNbZbEp6U9W+HUMMB R/jpzaWZfgtHv0l+/LxXWupHnesDy7cSiTSrD34sfWpokWUfZQZmAKOf8s+dWrWK1sYA wORwo2mxkJKLRpy9nWyQZnTl8ZLlRxfOxEMWMY9j+0t2nTG7unHPVrEOP1ezGS4e2DXY zBlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742510578; x=1743115378; 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=Qn+4G/BZfte1kQZajpdgC3z6H+wA6NVBYYf22eoImB8=; b=N+PyNxB7uQ7OlGNtz9cK+gEcM+xsWTi/V+YuSyS3CDFa9ACXpOMsixjdCK8aZAUALZ tRvuoYS9HnRwBMl1tk1GPfuQnUVf2ksUiVPp4QPeAKQ9XTR2ZE/qB33cgA7A8DR6dyUE QjZdCz+kqTJoLYjDI3QmSUWp70evqM7o+ZtQHjnoTcRr/vElzPAbNJ2J6kZNICks3C3s ADzTQQZbHRXDp+bTup+Kvlb37oEsNMmCUTCwnxwt+4vZ9K2iQ+AuH0VMdrkBgHB6O/7T Ww6iHH2N49CdGkrn3mPBv9x3NiLsNj1n+GwqIANE2VatX2tQF/MThUukVC1xNuF/F5ZZ Sd5w== X-Forwarded-Encrypted: i=1; AJvYcCU93u+sSkql7If9sOYHiUUq1/9tOK5Agrrak6CB1ShavdMnjnFly8IUljdDOHlxuirrtqLtXbCEPQ==@kvack.org X-Gm-Message-State: AOJu0YzVLHzyFc/d99oSekNSH0C63KWurhRG9Otca/xr+JyLnvKTnOWp osS2gu7D2QxEY3qAl1ZrLsZRxaTjaap0KumI18zXspXOewq5+Y6rL8wYthAqvQ3XMkRGzyTKDS4 j7Z2AdFln8e5rNUiL+UZKYmggM7xQ4Jkg0oWTAQ== X-Gm-Gg: ASbGnculg4bCh/AD2DvR53XQu885NsgXSiFtaPeFHl6tYquEeDL34LDZOW2N07xYGMM kTFE6sX97bPdHHuPKMUUTie6U4tGBs9JS1bbsSCCUnJVjf67YyNj4D8v3Ppv2RHTSupyrruFFwK FCKCNt9zryqrcwmAzZPeEv8A7XHMU= X-Google-Smtp-Source: AGHT+IGmYWppAb1TiIqTjy/w+R69Tu+tZXikOvPPA4dXCqNye2klzCsCnnoPJTKEOwtSTNPJ9gWuo2HlZH9leRcscHA= X-Received: by 2002:a05:690c:64c8:b0:6f4:8207:c68d with SMTP id 00721157ae682-700babfd564mr17209397b3.3.1742510578457; Thu, 20 Mar 2025 15:42:58 -0700 (PDT) MIME-Version: 1.0 References: <20250314-v5_user_cfi_series-v12-0-e51202b53138@rivosinc.com> <20250314-v5_user_cfi_series-v12-22-e51202b53138@rivosinc.com> In-Reply-To: From: Deepak Gupta Date: Thu, 20 Mar 2025 15:42:44 -0700 X-Gm-Features: AQ5f1Jo-nHEMu5qFdaTum9uSomYqo-G7mLCiMbL1c8nby8c7DsEke_Gukp9eNFU Message-ID: Subject: Re: [PATCH v12 22/28] riscv: enable kernel access to shadow stack memory via FWFT sbi call To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= 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, Zong Li , linux-riscv Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 6F299A0011 X-Stat-Signature: dd4cmz4qfzj1usx4fhjcruhoxskk4z1d X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1742510579-142217 X-HE-Meta: U2FsdGVkX1+odAQw6IB9HBZNtQm8yxJ3xkZEdSBBpb6oIxQ0SqXChDwOvixw6y1dkbYbgRQ2n+/t8Tx/ZEbyoxR/SE1gqGHT2wnZOjf9zpWXlvi58GWtxJ+OkfCPyF2/7tsEAtiUQe5WO4v75JY1zdH9Cww54IT5xDJWuWvmlnjXnA61ho1X5HnISQvtToaCEWwf7NZjT6Hhr+rmos2e9kzil4dnS0k3gYogyQ8IRDgXH2kJHgSlk4cxGG4FWiOxN+YMROHFcv0UHOwzVfQQJWN60lqOBZf7R2fu+iFtstNCA/QWlZgEqUqnib3VNlmVu7c/8jGlnyOR3DLd6irqgEJcWvIWRikDRZ10zT66hVquP2TAJApxLyia4UgZ28OQgjsQ8KDs9ArdAObeb0M3bzX/hwFHO0NyetASWYxw4Lo7bgDrugUdJoWblrSvZJYTXhCEflLwg82JjbCVyOelGk+zrmrEfIGf/1RELxS/3Xtu5O2QnwSjvun45xGmxt4JyhkRODHP7cPZQyT+mIgtiAbUzq8n2bDiAZrtWlROKa+Q+Aq2qKXg/wx01AsMzt2PeczpCcQ9du1TscMNUvBdtn3kaameuBnpk1YP0+08NIR7GhpjMpt3ZfE4SgsxwslNzZiQCXF4WT7PkIzbAPAcKq46yNd1B4HHo/KLssntVxOyHT7MIo6s3seqPpKHSzWGd8igyD7mlRl5FYLwehG6UM1Xrfszg1/cCnlBXFyIF8Lfqo50nLmxnaFzSrqzEW8727AWdl2P8KGGZG8yGAq8ihDHGm6EX/zN5ndrcBaL0LtJL5Wh6QNyDo4wcMJxLyplcAgWe4B0hQDoH32xKRvhKd8qnl4J/Y7REBHfdbjh7zD2PgZmtyJYGRnP+FjHsqVQP1aeSq6x6Q68vNALrtJe1mxCY8sj6C7m/CaDDZwRslSnOh5V47Fs7BTLimmV4F7oFyx9jkt6YDdE+ueECe6 cG5/7ukT cgQWGiwdhLsONavEtEC9L+pgW3q9VQKZFbXV6GuYYowzWiio0LAHoyC6SXJcN25gof6FjHq41Vd4Sgep6tkET1J7FrmSiIdXNUwptXHhNPzW3iIdROta0JD0iGh7U4MIqvjYicjjht17rA8zoLaI7J4kVM0SMDe+ucT6Qy2zUJouXhsYdtj2HJWZRdVHcONblF/uIHv57LF5E0/b9EDssmu4uMM6tiuq/f3kfBN7htIx5OR2uX1GzFwqiSXODM9EuIa1PUd+OOxZq0kk1mRTJTWsBEZAmeauhktnbRYL4LCFgYeRCTsv1nV3rEhRLJQYCsrzZK6KW2LtndFGHtaNo5y0G1kCn2J6XqkbxL9kFrFCsvbZqZHQI5bH86y61RZ2z70rqD1cNARYgiKZqR44pXZpsixpKOJKtx7XgD7vWZ9ThWOxCVnGIw/0th03tA8p1DPfnsRpWvZDphboeMPq6mx5ZojGkrKqNYohhdQEjhv5Ea+k= 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 Thu, Mar 20, 2025 at 3:10=E2=80=AFPM Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > > 2025-03-14T14:39:41-07:00, Deepak Gupta : > > Kernel will have to perform shadow stack operations on user shadow stac= k. > > Like during signal delivery and sigreturn, shadow stack token must be > > created and validated respectively. Thus shadow stack access for kernel > > must be enabled. > > Why can't kernel access the user shadow stack through an aliased WR > mapping? It can, although that opens up a can of worms. If this alternating mapping is user mode then ensuring that another threat in userspace can't write to this address in this window of signal handling. A kernel alternate mapping can be created, but that can lead to all sorts of requirements of ensuring the page is pinned down. IIRC, It has been debated on x86 shadow stack merge time as well on how a flaky alias mapping approac= h can become and weaken the threat model it is supposed to protect against. Simply using `ssamoswap` is simple and serves the purpose. Enabling shadow = stack access for the kernel doesn't have any adverse effect on the kernel. > > > In future when kernel shadow stacks are enabled for linux kernel, it mu= st > > be enabled as early as possible for better coverage and prevent imbalan= ce > > between regular stack and shadow stack. After `relocate_enable_mmu` has > > been done, this is as early as possible it can enabled. > > > > Reviewed-by: Zong Li > > Signed-off-by: Deepak Gupta > > --- > > diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S > > @@ -320,6 +326,12 @@ SYM_CODE_START(_start_kernel) > > la tp, init_task > > la sp, init_thread_union + THREAD_SIZE > > addi sp, sp, -PT_SIZE_ON_STACK > > + li a7, SBI_EXT_FWFT > > + li a6, SBI_EXT_FWFT_SET > > + li a0, SBI_FWFT_SHADOW_STACK > > + li a1, 1 /* enable supervisor to access shadow stack access */ > > + li a2, SBI_FWFT_SET_FLAG_LOCK > > + ecall > > I think the ecall can fail even on machines that have Zicfiss, so it > would be good to disable user shadow stack if that happens.