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 9DB20C369C2 for ; Fri, 25 Apr 2025 11:32:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 992E96B00A9; Fri, 25 Apr 2025 07:32:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 91B736B00AA; Fri, 25 Apr 2025 07:32:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7C0366B00AB; Fri, 25 Apr 2025 07:32:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 5A9886B00A9 for ; Fri, 25 Apr 2025 07:32:07 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id ABB1BBF5FE for ; Fri, 25 Apr 2025 11:32:04 +0000 (UTC) X-FDA: 83372352168.19.68F7F67 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by imf04.hostedemail.com (Postfix) with ESMTP id BB7EB40011 for ; Fri, 25 Apr 2025 11:32:02 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=ventanamicro.com header.s=google header.b=BVzcuxtD; dmarc=none; spf=pass (imf04.hostedemail.com: domain of rkrcmar@ventanamicro.com designates 209.85.128.51 as permitted sender) smtp.mailfrom=rkrcmar@ventanamicro.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745580722; a=rsa-sha256; cv=none; b=084H1UG/8wIh7MeTywUElw0+npDNMwwN2v9Unsv+ZkibOEWPkGAqXLeTFhZ9UXRoL1RVDw yVLPpbn9vFFyHtvHVIcdGOyMTbwddOJJStMLS9FqWLBt4qB9ljSAKl3CSXTyowszN16VMR 8oC5/v0XksHFrROZC1GM6MMJjbMY/9E= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=ventanamicro.com header.s=google header.b=BVzcuxtD; dmarc=none; spf=pass (imf04.hostedemail.com: domain of rkrcmar@ventanamicro.com designates 209.85.128.51 as permitted sender) smtp.mailfrom=rkrcmar@ventanamicro.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745580722; 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=gDHnSfsfm8Pky45upkoSAPit3VP8lTu/pCNcAlnlmqU=; b=oB1D2Yqu4MYIMaYUz7lyk7D3aoRqcoU4Zgrb4oQWQDpEvJLo8UV8bfmxwWk/kSoyC3IgeB Fu1CCfSMYvxMC+mHWLWROmpNsCBa3/qbB5cDCZM3zg82JPnxA5d4crfx9Va9XzSZt6QPU8 eHik/1dwmwjfe1e9E4DWfzUUHzthaDo= Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-43d16a01deaso1373355e9.2 for ; Fri, 25 Apr 2025 04:32:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1745580721; x=1746185521; 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=gDHnSfsfm8Pky45upkoSAPit3VP8lTu/pCNcAlnlmqU=; b=BVzcuxtDDFmx5FYEUvdmX1QM6MNDeVFy427Sf+JDJrSf1pRJV3Vnl5cD4x0RsXMsBT cRmSe6V+oWYULrKn8aW0hdjRnSHupLxEs2AFReltk4si2zXWty20nW11n4KdoMOdyiPy UwxsB1R2yzrqdMXndL795iYZD7jP3jBYaPLhFYabJ5xHtBqEYYMXIVEYqM5dP2BUxJOn s/qPOQjVJratBdPZKpLNWP62IYUDWe1Rmd9h2mRvTPlfsQ4+NG9A8kJoCd0OEouRhxR2 T9WIHFxu7PeHJs3EzPKX+ifXYGmzv+vvJbJb3y/lHrSG4bTuC11ncUbeyK+TuDIv7BZ8 ZqFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745580721; x=1746185521; 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=gDHnSfsfm8Pky45upkoSAPit3VP8lTu/pCNcAlnlmqU=; b=RbtLvVKBqkY3CnjgApmLby6ZsqBBAsH9xCtDLS9erpsKw2yhl3XHoKYpV+K+ujRgpi d7gxVpqI9YVLfrjuD5NiNvJ1bWa42KcdMUPsfGHo0djuvW4YjkgkQEzzzgISPA9XGqjP XMSQ1NEVSClt7rAEI7CLOWIZ/9IePud91bgPo5rSgyvbdQSwu/p5qmL/78QPBckvIRwM WuBmkOVfCtk0zT1tZlaETzUCNwo6FcKKhc+0p7qMomCF6cqXL9W+u7utu8VvHyJqLS8c PAf5quT6gnn5aH2AqiYDuYhhXJVlXfZ9GGB7xzvkLuAxUGEO4hwyUJ+Myx0HjLgcQCAH 31OQ== X-Forwarded-Encrypted: i=1; AJvYcCXujAG4bBtStlaxGMO+m3AnAwMRafymWP5ewnZBAwbrXBYuv7CNhBVHXSWPoakWwjr024gZaDUhvA==@kvack.org X-Gm-Message-State: AOJu0Yx53o3W51cfJdEzMBIlVJpMZ7YYUpyDlzxxrbLtjetm8jUfEl0f 1xr17ejqd/M14sJqutFAu6lbaOrLekHGl4daxyrqYj6G97D2TgKYL6RUOqA1a+U= X-Gm-Gg: ASbGncs46RiRoMbSqfxDIdUqRL0P1T93OO7tzsKZulZ1Q+EsUL54U/A9NAYqxRA19au WfWZB0yPMPT13FpXurztQwmdLAaD2p6vBW5WM2N2H0aK5BS/z7qoAied9BXTFSFU0RtmYqas1ZL FdSRI6V9VZWPeKakryQMK9JiUCtDxBOuPBQqmseXwnIvD/tLCrP/sqaNlARtqHL9m6jIF5LilsV zq7oOgEXyQY3Wh47lBpzLh5XP9rMu/JYTdADDW11EJvyhRFjxXrLd95+lxZ6j4ArPQy0apZ2p6I U9Zd6aLsgrAHcrZCefRzwNIaIoabUgdL9rVbgZA7XTrr3j4t X-Google-Smtp-Source: AGHT+IHRqf93ViQDABDgGhAB9vrTQizaMXk/z0DioGF+r4Jf0pl8X7PBzUSEYnMZMSBPSRe+pddQCw== X-Received: by 2002:a05:6000:420a:b0:3a0:6bd0:a4b0 with SMTP id ffacd0b85a97d-3a074e0e122mr528393f8f.2.1745580720995; Fri, 25 Apr 2025 04:32:00 -0700 (PDT) Received: from localhost ([2a02:8308:a00c:e200:84a3:2b0a:bdb8:ce08]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a073e5d479sm2137879f8f.92.2025.04.25.04.32.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Apr 2025 04:32:00 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 25 Apr 2025 13:32:00 +0200 Message-Id: Subject: Re: [PATCH v12 05/28] riscv: usercfi state for task and save/restore of CSR_SSP on trap entry/exit 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?= References: <20250314-v5_user_cfi_series-v12-0-e51202b53138@rivosinc.com> <20250314-v5_user_cfi_series-v12-5-e51202b53138@rivosinc.com> In-Reply-To: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: BB7EB40011 X-Stat-Signature: rf5xgmnup54qhng8bykmq3d8s3q4hezc X-Rspam-User: X-HE-Tag: 1745580722-961155 X-HE-Meta: U2FsdGVkX18fSaptDNhGckFw2lFmqgfKHC1FfOFFiR0aFX937zoX1ro1gvwSQAd8Pcu5Y+uExIZnydr4M3eP0L1J7JrdZ+wO+EnXjUVIuYuZv7a/Wntc2BpaF+K5SjRRWm5eRQ9acKWxo5F33j4TVGcQhHipN/xf0CrwQuNrgMpvcb7F433huXyVNgGQSpcANfbPnb1mArBKD3wKeNsEHNFT78vAWmez0SQ9olC+XVedE69prP+mSLI/1J75UlN7CKDugkP8DJIXH+qmqfd1tK297mTd1qBOu6jHoUeRKJqGiGKX1LSENLziJv2ZGslyWkD1l3xJCui8lrS3U3f74flLskkcNyid+yrpaJapOZU3NUcwSpmCdS++VtWuvz6Vk0EPjxMRUlYq+vNS1UnURnblj6kU5JL9MEQowT4Mhs+Q1BPU+2XPu0xtks9IeoDaIM2rXmLaCS5VH796i0ne9aMvEeNldKk2zKSWNg2+Sho1DSrpEG9k9PLTlXQwa8Z+7JoR7/o5iwxS+UbWxKTe2J7L2R7igIhKc6EQJkzgmZCp5SumPAAAIR7/YRL9Uk6ylXHIDiGugZKwnM32uxH+AyCr6KkRPjU4+NGsmBQ4C/H2g9M57YZRgeaf9gazFdp9JZVoP+mJDurGQ6P5Yb3bksvFjOQOt0G3OieVTLBPTrQzFqUojZOwB64XQnjkn+Fac+PO/JdKiJn1e5utVdYyN8iKEOB1wArUptlE7Z6Bl8kiRCRRw/f6hcSiK9XmwLMD89NWhirtyVCpR2etxnrDc5hRIKyyBP4m4aOqwQvejoC9vQxfzsZZbCaYcfv5qGlbmeptcu94omDDCbNpk7Ml22lfUTw5qJQ0QOBgQaU7K3bw9SyMFybKSLoQ/Drb3f2zLG3zwAp7MBvlu7gGI86fwaQhQOVHCSA9e7i0sAJMrZoV8tJ3dprdvCT+TwHJhaxuXWVVIyUbvvuc6D+BWTX er3AO898 Vz8JRWvZldSv32FHaNvrgucGfzeUbqF9fRY5nwYmIdy+LzDxyEFme3jZHGH2+TGHsAScFlkUxDI056GA5UgPPKKdRRN6yvXToy4qynPs1s090CAVVW6l9RWYOVY77sf3KfJm50sbEEKJYnNuOh15msotzJjO4n6+1+JBK7Pxo+dIrlplZe/Jk6jFOeiS+tm5zxHlviDUTrzWuTnsrNrXPICeZdLRN0pJ5+w22SYkA184rXscxpAKIdbIBnSzj8ff7hdGF5qKUtnO7T2DVo8W2nK6yMPExvS9UrU00fGaIJFrRVj8gEAq1TxVVDtPRderaXVsecGFVKSG+m/h/kMgcHJKf08QKvl+9FJ4FZoT+4gzzowrQQHfycHgiSvXxHPDdUmXq4ZIt33pl2Ux57hgwKuqkmdkNKQM7b7XrJ571Bi1IZfXuzOq2LabbYht1HvzAiDILwBrv41gNalvxv+WB6Bwk6zEf0VslN2NdwOVFxsfPwqKTzTMLov8g+pKU24EnLBKGf6SnaSLtjjZXR3Czt6Hn5n6WpY78cRSXXXp15iT7McZpPqthv4Srm6pT+BaToCg63b5ZPQBH1+MFxcikznA9jXbKQvAaEVvKqAr0mHaUN2R92xdFbkPZ/6SCY24OAmwqn9kcqH7VKu0PWjFolBtrf3LoAvNA9WLbCLz045bkkqsPPlxWyUiCOTVY4xK5uLWiu+tobT/jUooO/lYF/gtfAsmpHzD6as7HNjdh033c/cw= 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-04-24T11:03:59-07:00, Deepak Gupta : > On Thu, Apr 24, 2025 at 02:16:32PM +0200, Radim Kr=C4=8Dm=C3=A1=C5=99 wro= te: >>2025-04-23T17:23:56-07:00, Deepak Gupta : >>> On Thu, Apr 10, 2025 at 01:04:39PM +0200, Radim Kr=C4=8Dm=C3=A1=C5=99 w= rote: >>>>2025-03-14T14:39:24-07:00, Deepak Gupta : >>>>> diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S >>>>> @@ -147,6 +147,20 @@ SYM_CODE_START(handle_exception) >>>>> >>>>> REG_L s0, TASK_TI_USER_SP(tp) >>>>> csrrc s1, CSR_STATUS, t0 >>>>> + /* >>>>> + * If previous mode was U, capture shadow stack pointer and save it= away >>>>> + * Zero CSR_SSP at the same time for sanitization. >>>>> + */ >>>>> + ALTERNATIVE("nop; nop; nop; nop", >>>>> + __stringify( \ >>>>> + andi s2, s1, SR_SPP; \ >>>>> + bnez s2, skip_ssp_save; \ >>>>> + csrrw s2, CSR_SSP, x0; \ >>>>> + REG_S s2, TASK_TI_USER_SSP(tp); \ >>>>> + skip_ssp_save:), >>>>> + 0, >>>>> + RISCV_ISA_EXT_ZICFISS, >>>>> + CONFIG_RISCV_USER_CFI) >>>> >>>>(I'd prefer this closer to the user_sp and kernel_sp swap, it's breakin= g >>>> the flow here. We also already know if we've returned from userspace >>>> or not even without SR_SPP, but reusing the information might tangle >>>> the logic.) >>> >>> If CSR_SCRATCH was 0, then we would be coming from kernel else flow goe= s >>> to `.Lsave_context`. If we were coming from kernel mode, then eventuall= y >>> flow merges to `.Lsave_context`. >>> >>> So we will be saving CSR_SSP on all kernel -- > kernel trap handling. T= hat >>> would be unnecessary. IIRC, this was one of the first review comments i= n >>> early RFC series of these patch series (to not touch CSR_SSP un-necessa= rily) >>> >>> We can avoid that by ensuring when we branch by determining if we are c= oming >>> from user to something like `.Lsave_ssp` which eventually merges into >>> ".Lsave_context". And if we were coming from kernel then we would branc= h to >>> `.Lsave_context` and thus skipping ssp save logic. But # of branches it >>> introduces in early exception handling is equivalent to what current pa= tches >>> do. So I don't see any value in doing that. >>> >>> Let me know if I am missing something. >> >>Right, it's hard to avoid the extra branches. >> >>I think we could modify the entry point (STVEC), so we start at >>different paths based on kernel/userspace trap and only jump once to the >>common code, like: >> >> SYM_CODE_START(handle_exception_kernel) >> /* kernel setup magic */ >> j handle_exception_common >> SYM_CODE_START(handle_exception_user) >> /* userspace setup magic */ >> handle_exception_common: > > Hmm... This can be done. But then it would require to constantly modify `= stvec` > When you're going back to user mode, you would have to write `stvec` with= addr > of `handle_exception_user`. We'd just be writing STVEC instead of SSCRATCH, probably at the very same places. It's possible that some micro-architectures will be disturbed more by writing STVEC than SSCRATCH, though, so it's not an easy change to make. > But then you can easily get a NMI. It can bec= ome > ugly. Needs much more thought and on first glance feels error prone. Yeah, the M-mode Linux adds a lot of fun. I don't see support for the Smrnmi extension, so unlucky NMIs should be fatal even now.