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 35ECFC35FF3 for ; Fri, 21 Mar 2025 07:35:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA353280004; Fri, 21 Mar 2025 03:35:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B29EB280003; Fri, 21 Mar 2025 03:35:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9A3AA280004; Fri, 21 Mar 2025 03:35:54 -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 79707280003 for ; Fri, 21 Mar 2025 03:35:54 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D903A8200F for ; Fri, 21 Mar 2025 07:35:54 +0000 (UTC) X-FDA: 83244749028.22.8769AF6 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by imf23.hostedemail.com (Postfix) with ESMTP id D9ED3140003 for ; Fri, 21 Mar 2025 07:35:52 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=ventanamicro.com header.s=google header.b=To+lAx9g; spf=pass (imf23.hostedemail.com: domain of rkrcmar@ventanamicro.com designates 209.85.221.53 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=1742542553; 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=uE0YN48K2zRXVt+YdSQ/RPd3ayIjfmSlm7kfHTz7O6c=; b=Dk+BwERN4AibJycenGhcW29a/CUF2hFnFkRwWKgPjeI0FHOeJifSbU8b+wifilIkTP2pOI G4FUFggIqQfMn8inXIghgYYhe22IdAXzpeEEP0OaPF3Brq288LCUs9kF1YVVc7quMJLrpj 4eI7TTeDGeeScT7QbkmwRKUzNpegvr0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742542553; a=rsa-sha256; cv=none; b=ZvSfEEMkr7zOc1FHhZTT29ahsEogvJXwE6+yrOHyhZCzPitZpIVtCdv+1YPGJo9dtvLSAV 5ujej3ID0D48WKvSjWRP7Y7ibYbTv2OnrB/0P0Cr3dtOzqzr0EtPYNApY6wdIpvbNSP8IP XnRBVVyQhCDMr6fVfgtOnyj2pyMFPgg= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=ventanamicro.com header.s=google header.b=To+lAx9g; spf=pass (imf23.hostedemail.com: domain of rkrcmar@ventanamicro.com designates 209.85.221.53 as permitted sender) smtp.mailfrom=rkrcmar@ventanamicro.com; dmarc=none Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-3912622c9c0so192509f8f.3 for ; Fri, 21 Mar 2025 00:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1742542551; x=1743147351; darn=kvack.org; h=in-reply-to:references:subject:from:to:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=uE0YN48K2zRXVt+YdSQ/RPd3ayIjfmSlm7kfHTz7O6c=; b=To+lAx9gzLE/sxlcHqr5ahNENCM7NJjqRakqnqF44JnisoaKxrJc9/Yk2hs2uXEoY9 gkB9GAFPQkrPZ+ydos+m4tVuiZR17x6esFlHSn4acgYEnnuP66KCuAZsHMk77GRIozLg 1Fry7nKiO7TegkAsIBEni0ioWmBKhqO7wcfI4VvVeQe1APu2X2NkkUq5i3+CtIBr1qrQ QH5L2AV1gWef6ncXkvUBKCSF0ovJ+3s86UQxLiqn605mlx1TQ7TCSnPlF41I2SVUHNH0 xounhDo0EedwaGMrYJrA5JYvzYlPBX0XjOM1P+AxDMM+mbQRCUPhv7vzJqqlr1V+VMwK ykxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742542551; x=1743147351; h=in-reply-to:references:subject:from:to:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=uE0YN48K2zRXVt+YdSQ/RPd3ayIjfmSlm7kfHTz7O6c=; b=P09YEQvS0U6Vk5Q6ZPjUDR1QjSh7Sz/Cm1hteUS+R5be0tGnKRc77bZU6qp+EnJynJ 6Nc6woN1sns1M1C1UpJ4lF5+NEa+wLNbPcRsxedBhgJWV6MuMtwWR+d+w5nFL5eXzN2A UkRgGoHTcc1kbnrS6lkkmBnmzXwBoGixjsk9sHbEb/aAmoDOMmKnYSeL9KOFogotmrm8 epGZbmPH9OxDmVnL/pNfd2YHWdhd+/aWmlH+KeZ8ys3DQW4kB4+o7SCB8zCCB0bGy8lY mEG640/AEcvUmbj+77wy8eTAqUsPhRuFQc9L+97DhM/bT7vfUwmwFbN/aBvAbjEKzDU2 erZA== X-Forwarded-Encrypted: i=1; AJvYcCUoGXS069MGmO+5JgpfkkbYo4gvYNCHXKTtmP93CRGKriRD29Nzx+mQi3d/1Ls/t65Ua9yCAxNV2A==@kvack.org X-Gm-Message-State: AOJu0YzNP1hUxZd7vt7o4OeceI318xmTFMnDLegmv/3RILLublDBlAo8 XWdy5/nej770ERgq31w/7iL8yiVoNrI63niZ34ooOBh7hMtSFLOEX/Jh1me9EFs= X-Gm-Gg: ASbGncsc/NbOBN0Io7Zq4Ek8bfW6cDdcwbQ+Rt640rNDPQda/RcS5zYu70ZaxfQJnYi H6QfzeWUJG5W2JijB5+GhKj3DtrkE4eYPFvQgx0J9KOfn7DMs8+vbHb4GUHhcffaebRmlh+vACU HRdEZizEnO2NIJT8/T5QiankeZaFMI8lUuOeWzbji0lcuhpmM2dcStQzKu6AJDE3rqQPBW4PVtZ zlfVhZQUtFoYFGiJwFyR1mkDwwKR0M8cJD1zokvdrn6GUpB8xPAUvxtFj1Ds2ZU5nFAUkXbGH9U Yjq8wbI2cXNAdfQ/sq0KJD+lgXPEYWfOC0PFM3pSTcLf/uvRBVw/EAUw6nwH3JIXdHnasj6H83f ZI3ORCCMGmzZ1CLI= X-Google-Smtp-Source: AGHT+IGZStgpQKD6s5SPSh0Un5MoJV2dCYto8osYkw90aX9XoWoskpnSL/J6+EfI/KAtzzUYKMCKnA== X-Received: by 2002:a05:6000:188f:b0:391:277e:c400 with SMTP id ffacd0b85a97d-3997f941b74mr851925f8f.13.1742542551154; Fri, 21 Mar 2025 00:35:51 -0700 (PDT) Received: from localhost (ip-89-103-73-235.bb.vodafone.cz. [89.103.73.235]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3997f9b3f7csm1592933f8f.49.2025.03.21.00.35.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Mar 2025 00:35:50 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 21 Mar 2025 08:35:49 +0100 Message-Id: Cc: "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" , , , , , , , , , , , , , , , , , , , , , , "Zong Li" , "linux-riscv" To: "Deepak Gupta" From: =?utf-8?q?Radim_Kr=C4=8Dm=C3=A1=C5=99?= Subject: Re: [PATCH v12 22/28] riscv: enable kernel access to shadow stack memory via FWFT sbi call References: <20250314-v5_user_cfi_series-v12-0-e51202b53138@rivosinc.com> <20250314-v5_user_cfi_series-v12-22-e51202b53138@rivosinc.com> In-Reply-To: X-Stat-Signature: 1gpk94dw8tnyujs9i6oukutqrdxid8zn X-Rspam-User: X-Rspamd-Queue-Id: D9ED3140003 X-Rspamd-Server: rspam08 X-HE-Tag: 1742542552-317030 X-HE-Meta: U2FsdGVkX18XvIGTH+pG1GFIk9BahoHfibBDL3FJI5SVZDBnX9dUq1Z5kIWO8GC0aK3sua0Ge/e3ONPbkyaaYDrHkIobl9hfIAYMCTai2oVbwgamznEJDFeSfcsfHAaejiEAOvnonGaSZz3YY3ybSH/5MySiW+pIz6sb5ddYUaKv3XP/Q3zKZDoLs7gYbC5SQK4kU1p8mC2W5a4Hb22pp8i5JSBE6w+MBIXOERxAcu7yg1OUwgu7zAHlWDjv8nwUYyujsMPVLmbSM3mvIbfLjJuYLbLoYGqw+VDxo7k0sHeA+5nsr8ML39Z5389WpLYM2qXgs1azqGBAQ+cFXzOPjDTxyXN4LUSr16Aul9086H9cLyx96i+kDEnrdYyb4OR5WAiMUDouAxmA81lTtPxJSDEv94+L2M68rcK/EeZE5XQP14TgLkC25//OmgDAu/1rP3JJaBC+898+U0iWJoUAxoL55n8SKisN9haKUZ2cFJA/bokeMmlS2GH+6nriHT7Syz27puOxUAaJ8rTNlWnhwbEH13WmlMfhjVAUIu6rB6HIK5n4y+bzbAojL+GdQ3aFCOqw/q/ErFjTvmQAOriCtOe8NyUnTo70EWyP/w2Jd4dqX8X4fWLpWUhRf6S564cY6GjUPNZ2l62bbJxmKB1nMk6toNvoVOs9mf9tDCVxNLA/Z5k5YcO97vXHMrWITY315tR2gT2807qR6srHYuBuHl/DpBNEPwUhae1Kcom/c+oEfBNavBvXhqXnDEhCd8wYdfrH1+11kb4rtfZSe+5thPK4FXRwcLVsTuoQYTr2NF36hJ3TxiqpH1t0AYoAqF15E/k7PiLlkFtvlHn1PaTdVSsyhBrV45SB7oTRYLaK3SLRcnlShJQrF+3STI0Loih2xWJuyW6GbJAhiHRbkEDkp8A87ucGaDtnTPg87NdmTBrYqjnrO6A4z1DibAdkaRr4h0nRzHe3/znq6fFDl2Z tbiqy9OS W3T6oU7xBHIH2L2GB1qxl9wWOgOvmxoqfYE2KGqpCJlX9hmKh4WvJFS4CLK61c/b0ZnUzUkqlUjhBsIWG+sCHJcn1jKm7/ym7qjUAwe1t0eIP7FQBr87P/VShvbQhmMpcJJ4Lahu2a+gYxf80mLGugRGmMrxkA2HK6/Cu8T0UgkSwQw+S1Sz7xVS8ifJ6YL6EbyccZEn7l8gAvoHkbrbAhYkVs6j2QXgcbHC2QLy7C/KUKJKX6fpG+KifonChQ92nDi7FpvW7AYgXIkGD6PZmWkmtAmF0AJ09GKwBJC8hjB7lhzfOzhqefRjvUbDUB0X6FheqSTTvtYiLvlkfkCQjETk7NzbVSwjlzMP4Gke8Wpq/XVMIVxmjd6lP+X7t65HCKmflv1a4vM0cOnljqD+BkQ+zBaERhf/G6pqf54I9mdhn68gOGMeZQxNl++sbFnx1rq0Ubyn8Sumw77qs5L0WSw4w+hnBuIC8K33dgy/DpLibHmj9q943l8UT8yreXHLtJcN1gVntkWnpbzQfkcuR7Lq2lkQzWxuaIH3HH6GFJIPsTiAF/0I8xkuqPq46PP8xE5f1FENGfN+OfVXzq588596wEVYX1+rjpZ9jTlxiHH+81EDQotE/VgkvmBuHpBhaMRquAWsQGgT1kYyrsYHIcLV7quvorAScwyVKl7m1xz4a7aA= 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-20T15:42:44-07:00, Deepak Gupta : > 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 sta= ck. >> > Like during signal delivery and sigreturn, shadow stack token must be >> > created and validated respectively. Thus shadow stack access for kerne= l >> > 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. Right, it must not be user mode. > 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 appro= ach can > become and weaken the threat model it is supposed to protect against. True. > Simply using `ssamoswap` is simple and serves the purpose. Enabling shado= w stack > access for the kernel doesn't have any adverse effect on the kernel. Makes sense. We just depend on an extra feature, because we should consider the case when M-mode doesn't allow S-mode shadow stack, but S-mode can enable U-mode shadow stack: >> > --- >> > 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.