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 97DC7C369AB for ; Thu, 24 Apr 2025 18:04:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA99F6B00D3; Thu, 24 Apr 2025 14:04:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E32CC6B00D4; Thu, 24 Apr 2025 14:04:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C102D6B00D5; Thu, 24 Apr 2025 14:04:05 -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 9B91E6B00D3 for ; Thu, 24 Apr 2025 14:04:05 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3A2501D0043 for ; Thu, 24 Apr 2025 18:04:06 +0000 (UTC) X-FDA: 83369711292.06.C143F77 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by imf29.hostedemail.com (Postfix) with ESMTP id 3FD8312001B for ; Thu, 24 Apr 2025 18:04:04 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=MjZ16wjh; dmarc=none; spf=pass (imf29.hostedemail.com: domain of debug@rivosinc.com designates 209.85.214.180 as permitted sender) smtp.mailfrom=debug@rivosinc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745517844; 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=R+2ifGTP7Zuk1f3PGxpKoh8D1eRLE/ZHAefBGZIpiLo=; b=yrjBxwVtO9V/70KwNUq+Dq3IWw6/O8PYQH5Op2Wf5aZxlex2hfBtH/6ikabLfqbc8V80DN luurhu/PhZL6bVLI0s8RmGWCBc2J2d+bEMTFUSoBH3Natc+H0mFvGD/ELqLlXbpe2uxIPL Dd9WW6F/6Ewit/tBLs6wMfAVFXtgDTQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745517844; a=rsa-sha256; cv=none; b=htZnyixrLoPGPTR8ZpWzR7KRJoidx6uwL2iG5LGDD1/ZJ3eV5ZLbpjT3VjvW3lRqwJ4WWo VK6k25vsSsCfIGfK/Od9OoeW66VRTxqIBs5fElK+zvIo3QgfFBLZmD0S7C78QQQiwLAUwF 6Mf6S5aQO62nUcCctQXTmxlGqlPJcLc= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=MjZ16wjh; dmarc=none; spf=pass (imf29.hostedemail.com: domain of debug@rivosinc.com designates 209.85.214.180 as permitted sender) smtp.mailfrom=debug@rivosinc.com Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-2295d78b433so16307285ad.2 for ; Thu, 24 Apr 2025 11:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1745517843; x=1746122643; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=R+2ifGTP7Zuk1f3PGxpKoh8D1eRLE/ZHAefBGZIpiLo=; b=MjZ16wjh7evQWNdBEeihkLO5BqEQGP0QkZAywyeiysN6e+tG8vXw166Kc28L4wTLli z0gqxupuQsivknHciuqR+Ohv8RPssXHbFpRX4Urg6XOS9dPyFBotyx+qOYrugd4D8W4/ uai3EE/ekfTA6LT4jTbvqef19ZKvhV7KU8nZksMdaWIvTjvC/f9Ei+QUd0yU1Pa6NO21 aAYpV8BL3ZMX9jQ/+NRDILeXX1kdFqY8bHLHcZYTQrj4OQTz18XbIuUo7F788WyLGkOs q5NNdZaqdLBKanaIfS0MVAw0JkmpQkzN0sKUHrU3IAxqPsYXGATl+fg/laBNCKXO4qlz JyHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745517843; x=1746122643; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=R+2ifGTP7Zuk1f3PGxpKoh8D1eRLE/ZHAefBGZIpiLo=; b=LRPWRrKFxJY6wJHYzhzDfTDfXR9KR0iC27utPLaypuuqDePJ/mPR+n5oZ5t38Fb03R fxH/W5A4wyVAAcNZFLxmJB8UJ26O9Q352Q+KTmJNYJTEmB86BN4JskmbNTSSHylhwkMg AutlVEbu+2M6RP2JBlXMCLDpWG2RqfuoywntqyPw8uj76JHdryq6ov9hv44xfmz5Tlem jdEQbW5wsxX/6u54shEXT0Pa0W/8L8ihUjiBWFEbV9Fn5KSjP4zDMbByfgBkW9QEivvx rRRut/NZ+L1hYHYayYKraSTPd66YwDaYiW0Mxy/Yn+zKXL0/HUv1/pySXsb8ZIq98xnV V6IQ== X-Forwarded-Encrypted: i=1; AJvYcCWhk3zyeFszBQybx1UXrynk79Gr+P1F2epwEXRIzCBME6PCHOClvdUlE0td9i5elihsRbos8R98JQ==@kvack.org X-Gm-Message-State: AOJu0YwB5WBIhm7f+M5kwwsx9NV7lB+7JlNkcGXrKf64Dgk5VyJrCWoH 667zbzacgGVvUuh5py+1H7FXsLd7evkdKSerwCc3peZpVeItZODuyji9o3Hg0gw= X-Gm-Gg: ASbGncsz5awJqrj6Ll8TLyBkPw5C08bSJH4mKiHURGriEgva5wRtXuTnPvQgqeB5mBJ k1A4IT1Gk+nk0zIHod4JHSMQHj8RN07R78wFpjtzn9wTVeQLH+xlz9p0olR/YpBImF702SMZIGo GbYiFXL89H1IZUlxonl7ArangSlRvS1ZGIj2wgyYbp4XYlyMCNk/nYWEo9z/khlD7hyHPgqrCiw Ql8Rto5NStKxgRWZMTAzf1/dPL28OlQaQGiu9zR2JRzrK5RNpWZ9lwWk48ghDlYOlJJVEMO5eid PNMYzFapIU4jyyGRwf2nBKLHsoGVSRb9AsuDvddCjMMyLD8vx2i8XOJ+BLnH4w== X-Google-Smtp-Source: AGHT+IEwApZFffChVQ3IgP8GwvBv+BNm7qJFv/s7tyP4mivow/7aAesEdu2H5hIh83xgouvcI3whKA== X-Received: by 2002:a17:902:cec8:b0:21f:4c8b:c514 with SMTP id d9443c01a7336-22dbd46edccmr5459035ad.45.1745517843026; Thu, 24 Apr 2025 11:04:03 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-b15f7ec0bb2sm1513897a12.18.2025.04.24.11.04.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Apr 2025 11:04:02 -0700 (PDT) Date: Thu, 24 Apr 2025 11:03:59 -0700 From: Deepak Gupta To: Radim =?utf-8?B?S3LEjW3DocWZ?= 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 Subject: Re: [PATCH v12 05/28] riscv: usercfi state for task and save/restore of CSR_SSP on trap entry/exit Message-ID: References: <20250314-v5_user_cfi_series-v12-0-e51202b53138@rivosinc.com> <20250314-v5_user_cfi_series-v12-5-e51202b53138@rivosinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 3FD8312001B X-Rspam-User: X-Stat-Signature: uswsbr1zugnnw6qys71jojor3hnthfe8 X-HE-Tag: 1745517844-845901 X-HE-Meta: U2FsdGVkX1/mzAb9/8kqkq/QGtFzOzyktrxHgKD2Jy0ASMZdXobIxK9zMZcmkQoMLy0crEgqmH4DxzYOShtX655bhkm+iMOTvRUtaNLKVs5NuKRxTutrkScGzkvYHOp5JeOB3ibN11QORCkQDweKUi6O5QVtBXf+oVetbCLEcAjNYiIFZEh5ilC5x65GurVm5Ece67k0eEFiK5CdrQdc4k/wToCmK5Zpyc3eEoRnV2+6GE7dKwM4MnPZ49Anuu3zKKHbzfgb0bROzJE8arF2L0/s9FYNI1rds6l/XQS6SYgdPlfmqEZMjf8YIJL3N5KxI69uGWmbxTso2M1wj97ooJuXFNXUE0h/CyjzBPYB8KQUglMskb/B6uD6H3vOVrwSre/Rophv05KvMCAn4mogloFumrD4MmSVEBgBvy6aPGXNaPPKxqaEI8CEhRDVkhPd8CnWSTMk7MKZSY/A/0eAtjmtCOajTfljZY5fmT2RqHwCmuAAoAfhkgn4vj6Rq5hZbCbDPKtanAVhCDSctsKdL3WXcFoNnL0HP/fgoE+NheXfPYfVWn+BI27MtViyQLcWLR9AmSIsFk6a3KXrHVzTC3xxgLohSq5z8Q6ecd5FlnqQBFIIyW7CFzu2tx1ciyjIpCGRl6wdFSL9w1iUCI85wpc8GkGIEqnK29/IW0doWuOmWfQBtRpvnlaFb4LTCuwpKeMzc99xs3KWc0PapsIVS/lF4RVUnNSANV3i0JyXbwvQYn/0w7LZUs8Y75/DLxJlhqOBusaIgYmL552ddKJZE9XaOTi0E4cWlNyYMClR4od/D1gZHCfHhXVueFP/ur2cEMYP8f86uKeWVdxq2VZ/qo50DGa/0fLAVzpnH0+xsOOhCkIHmR7nGGFxoucvvA/rjlXPkMa1dPc4ZdTk/FqayPcm6VNU2gF2VF9fmVLo40XaCwHbPlzO/sHBGBd3cmO+bnh9gvc6REB/eErPlPB zI7imfxd J/yMcTkCSMdapErjHqYtZo2G0YInJzE1x0m6hcReoBeeTEZKefQ5JHsfeu9eLcCkiHprN2MmDyh/Wn8VFfM/xt4TSZGBa25SrgO6lN+8ali7eCxpVYDjcryBhYVbYGeOAO68j0krfx8LLyktwdl5DFXY2NNEtfDIctrfCEiK03n5eR3hARhqKBk16QDQoTt6kQDpXjbq59yqVCSkwJqJrzRGjB0byspYg3YFY1rwkIDTMxe4tYRHPbyi1Cp8uHVhxewycjdEJUIyzFqEvAnRRBcP8hKC7ovKtL2PDmdKu9qVQ2Iv7+S9DGtZeyZijjjj/c8MJXZg1HBYKqObD/5dwd1vAT/yElQrTURABR9QQOqxVpN9j6qLpWboeWLrHNGt9Jjp8b3ultbX2L7L9bVOOYmIFL3UqhW5WwNL5MMGaVNxN5e0pP5O+g7gcudIgmE66aAHO2TLoVscj3GOBnNROOSZQID4mLIkZAAzL4wqme5n45aGIE7TyAHYe4wdPppyZ34D1VEEuyUj5XEZAoPzOfsyfw7EJf0w8gAcpZG0PBFI/WTvU4ml3XjzyZ8uU4DAyxdQVngh4fGbvS6P5hziklobI8wxrSjqI4Ip2 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, Apr 24, 2025 at 02:16:32PM +0200, Radim Krčmář wrote: >2025-04-23T17:23:56-07:00, Deepak Gupta : >> On Thu, Apr 10, 2025 at 01:04:39PM +0200, Radim Krčmář wrote: >>>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 breaking >>> 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 goes >> to `.Lsave_context`. If we were coming from kernel mode, then eventually >> flow merges to `.Lsave_context`. >> >> So we will be saving CSR_SSP on all kernel -- > kernel trap handling. That >> would be unnecessary. IIRC, this was one of the first review comments in >> early RFC series of these patch series (to not touch CSR_SSP un-necessarily) >> >> We can avoid that by ensuring when we branch by determining if we are coming >> from user to something like `.Lsave_ssp` which eventually merges into >> ".Lsave_context". And if we were coming from kernel then we would branch to >> `.Lsave_context` and thus skipping ssp save logic. But # of branches it >> introduces in early exception handling is equivalent to what current patches >> 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`. But then you can easily get a NMI. It can become ugly. Needs much more thought and on first glance feels error prone. Only if we have an extension that allows different trap address depending on mode you're coming from (arm does that, right?, I think x86 FRED also does that) > >This is not a suggestion for this series. I would be perfectly happy >with just a cleaner code. > >Would it be possible to hide the ALTERNATIVE ugliness behind a macro and >move it outside the code block that saves pt_regs? Sure, I'll do something about it. > >Thanks.