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 26BF9C369CB for ; Thu, 24 Apr 2025 00:00:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CF2D76B0005; Wed, 23 Apr 2025 20:00:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C78CE6B0007; Wed, 23 Apr 2025 20:00:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B19CC6B0008; Wed, 23 Apr 2025 20:00:36 -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 91EBA6B0005 for ; Wed, 23 Apr 2025 20:00:36 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 424D9C0749 for ; Thu, 24 Apr 2025 00:00:37 +0000 (UTC) X-FDA: 83366980914.08.7985833 Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) by imf27.hostedemail.com (Postfix) with ESMTP id 117CC40004 for ; Thu, 24 Apr 2025 00:00:34 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=nSUFC7V4; dmarc=none; spf=pass (imf27.hostedemail.com: domain of debug@rivosinc.com designates 209.85.210.174 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=1745452835; 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=S5OcT62i+cl9aw1kw4Ux6AcGa3HwoUmmaKY882iOUVM=; b=FtdKodouIlffRK+P7O3r7Hzt6+lGpT/ZHVIzeIvRjE4j6MQ2ABAiMjeHNpx6fQo6iALg0t syIVMtcX+3eexKpExIUmBEQ9EXlJLm27ifAzvJDPCzKESWesLni0lCz5EFSnBXR9NR6KnS 7SC7mfu5qpGgfuPgTe6icRgUHnC95LM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745452835; a=rsa-sha256; cv=none; b=l1+yZNcpBdlxnT+QUjxoPnT4qRPDxo4INzzPmZ6XprDKh8ekx7/DI7jFYvLFQPcQCmHwqM cIhA8EMQrwkoIIKDvNJ3jZ15bJ5uWemAvaoW3xTyMtoZ/b/p2zK6gQ+IDlyoIiCaINQhbH f0Hmb21zaEYECO+A+/ClRvqclZNaxBU= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=nSUFC7V4; dmarc=none; spf=pass (imf27.hostedemail.com: domain of debug@rivosinc.com designates 209.85.210.174 as permitted sender) smtp.mailfrom=debug@rivosinc.com Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-7399838db7fso482333b3a.0 for ; Wed, 23 Apr 2025 17:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1745452834; x=1746057634; 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=S5OcT62i+cl9aw1kw4Ux6AcGa3HwoUmmaKY882iOUVM=; b=nSUFC7V42gTyQKAhbkpkuxtxk9N3MMqkC9nt6xr2EnrNqRiR1lCkt9BY2pvPmwQnY3 uyoopiCbc7HuYBkOnC0oKOWGMDS1ii14GzL5B8VEZYWlmSvUXzsJXEswHc9yLyr7cxK6 jeBWWJmwXma5LVkOLns/p5cPca7CBRpHr5R++kfbL16+ijry453vgTDTBvQ9S11uG0Ur AyE8ZWoQaD+LJi8bD33DjnKcifLHC7FIs1kgiV7W+/F2O9xPWwu4PSwBeRgeoIzZZp8k lM4ccR77WyktVzqKpJmy091DS/zuVUwhLycU3FCZ4KJoVPhJ7CdbMUKL0rhFhZmzHWP9 T7LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745452834; x=1746057634; 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=S5OcT62i+cl9aw1kw4Ux6AcGa3HwoUmmaKY882iOUVM=; b=s9S/VJHi3vGcXvj5U04jzFR+/FZCMjoJHUXzh7EW930wfVLBBnVRFNV97dNSuDmHbu 76H9UHeqdngsz7Gxm8ev29uUr8TudbXEmJwn3ltr54e5a4QZdD9z4v6rvGSlxfYDUBJX 5JuLwu56+xeCEOv2xWOrp7aoA998ohrK4CLz47nrBkPmCuQwN8riND62jsOF25mCJock yrx+O1Sj54Bu1zARVu50Fmb5alJ/j3S4Kjp3oaN5UI4KR7sicVsirTMWP7DyK7Gm3FAY xtY4BJ//FHvGLoZiKh2h8F+V3ig5TBUkJ92UlJkBZ2msqUGRYrhqM2tSXSD1vxJ7pYvs jptA== X-Forwarded-Encrypted: i=1; AJvYcCW3j0FBbGXgEEHA/Nd/FjPQ38wSCybQU7CW/6dYpzhNYLAfac4K55g59dbY1rqRr3j/mu8LvgsgRA==@kvack.org X-Gm-Message-State: AOJu0Yx9sCPSGfT3QEOEE2UH/gXt3pvrahTCBZJakqi24BIxDUDS0dI5 onbn3Pxf8w57VCUKNq1r8kZupxqQ5J5Oj6v2V4GJQqixW5VzW2Nim8c3+1OqiRE= X-Gm-Gg: ASbGnct1+wHvds/3xEaEr0IKVPUVbUzr2M1fVi09o3Fd4HaJk9uemxzfYsHha0/CIZw 4fkKOciAWwNoLyslXhOkAYjk6mJMPbF6WQqMaSiH0GQADCsd1G9r0vxLUEGwTxePQv0VVjjXjht IQp+UgPtl6u5j4MOaE4lRdrgPs5r+80FVrFX16EEfotf5FWw7grSrw9z6LLWEhriknTwdHpSlBk 3h8GrlK2Kd8sMFgWtSR3rU8gcUn8zPJto97nXhOgtYeCbtNRkRQ0mjb73mnxipl/5yDmwdhOZHw UtePPc/HiZ0RxtmeYYzIO7xCV40kQI7ZUX0/ZWKdzqNHMwMQsxk= X-Google-Smtp-Source: AGHT+IH4j35h3jLwkaElmed40lsuZThIxCdtbM8R+7icxou6aZCYqN/7j54Ho7tdgxWbsJBSD2dEvQ== X-Received: by 2002:a05:6a00:3a1d:b0:73c:3f2e:5df5 with SMTP id d2e1a72fcca58-73e2680c3aemr381304b3a.9.1745452833588; Wed, 23 Apr 2025 17:00:33 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-73e25941cc1sm177897b3a.60.2025.04.23.17.00.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Apr 2025 17:00:33 -0700 (PDT) Date: Wed, 23 Apr 2025 17:00:29 -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, 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: 117CC40004 X-Rspam-User: X-Stat-Signature: sk6srd1yge9iirs887kn7tcoz37q1xs6 X-HE-Tag: 1745452834-739622 X-HE-Meta: U2FsdGVkX1/TlZRtFPF2FdVE9FUMqWfkD3wsnwTrImhu7pbNhf51YrJiOVTgcaje6sbv4P6gURYO2B3PqJ/3xyQhcPAxEc6uR7QfGOVogtGjgW38uLap/yzR6UAldBl8bp/s59m2vTdKCnkNlqk3S7kfTgq7w4ac4vNFcew94zSn5K90YFrb11HOA1wFai15qWPknQOwSGPyUn09RhcPv/zOktrohu/QCLzRIsNhnw+Aqdpy4S2/CelhK8KkAXgbHe3PI/ms25OJ/qQ04QKfnEV/OvMTbtZ83h8JbQfVx8xTtku8xX+IMgd0MtYFNZdsEVcfcKCgaug+qZhCWxFWwdHnGH46312StsYNO8SxJNnFTKMml1QoWHKq1G/D7f4G1XWN/J5+eHSp2LD7gtfaVi12dsCqfh8la1qDpMTlhNpBTRx56Fn3csIZHXRftHRq9O3ECt0gNXeL4js96HJTxqmOMc3wrvxApDHJVeyu9BpaxoiOt4ubWruR3nDcSX7WM87Ri6Qa89rwKpt73QjwIxqDYORQi0YEBmI/n86uTugKut4choTlouE+R8wx3sMc/P3D6/N1UL1mQiojHc0IdQev/bGXgGpJzdhYYEBnw4TjeWxArYXjp4tZQvEaatK7IYr7eVV7/8b/n8QQKZJ1Dn/IKnqJPu9ge2SfKDKIMQTS1j4sLLd3KSGKJwbzCdFgQkHRGfzEvHOnxOQ2pI8iyoA7XQ/Zr8Z5AGOMAauOelb3reLRcuaKyq0UtaraEtfdF28tIt3irD1cVpoMkDCFbQLGFdl4/55Yui9kbRQLPRj1n/WwTXqHC8m16tlGdxXOicYntnfkQSJPQ0/3W1Py4tlUNEw9SV4NW9hRH2xJtVcASoZh3UodWU+ohQCkVrQTXpgJrhgc/+zeregEerPlGQFTdErk1NA0KElGH5GmpyNRIBdx8VHguQvx5Qh0XKPpFy6kYvAjPcZZFGO39dM astZmDAw mXCiM3ZG7pYiXEekSeBGVg8GFW3OxKFXO9wr7WqvO8l5I89ab0fn00yuCR0VeYLdQLYN5Kp0ZiMX6RWnv+DolnTkyYZrbgzG1pnVeUx2jVWzMK9PJCuanKi3nXsONvKah3uVqVIh+JRde022KB9uyeIMD11ikMFkaITTYNcmcSDNVKQc127KczeWJ3AjRNW5Ttv/sSfE+Qu7rnHEGo33uwZHc3fhRAPWoHOnRBG527/q6I8Q78Woni7cPBLxMsrKYYZXpH9a7s60Xzg/QsDIJgN2BJtEnDQPUJQdyuOOQXzjdDwpR3pdrvxyhXUkrwZsGkAx8hCCTQq+ApXBcR5DN0TAVw3HClSDLytsclwpGW7euvM9GLSjBQWF5Hd3bA40iCF7vczjoqun/kZ/z3d38nVARhDn+FicvHHbnpAnWDIZDouD/HanZoj8wpxHZjE2DaXmoPHXXZxG4YqWC8WpprEBirGstQU20WsRmGav7yXtmu7G7U9PDxjkKFq3Hd5V9Rs9uf+3dBaAK71AiPoEjuuSCpZLDC2Keks8ZIU2GRJRPqgwKQ+EuD8wV3Ss1mXpNTAby 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 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/include/asm/thread_info.h b/arch/riscv/include/asm/thread_info.h >> @@ -62,6 +62,9 @@ struct thread_info { >> long user_sp; /* User stack pointer */ >> int cpu; >> unsigned long syscall_work; /* SYSCALL_WORK_ flags */ >> +#ifdef CONFIG_RISCV_USER_CFI >> + struct cfi_status user_cfi_state; >> +#endif > >I don't think it makes sense to put all the data in thread_info. >kernel_ssp and user_ssp is more than enough and the rest can comfortably >live elsewhere in task_struct. > >thread_info is supposed to be as small as possible -- just spanning >multiple cache-lines could be noticeable. I can change it to only include only `user_ssp`, base and size. But before we go there, see below: $ pahole -C thread_info kbuild/vmlinux struct thread_info { long unsigned int flags; /* 0 8 */ int preempt_count; /* 8 4 */ /* XXX 4 bytes hole, try to pack */ long int kernel_sp; /* 16 8 */ long int user_sp; /* 24 8 */ int cpu; /* 32 4 */ /* XXX 4 bytes hole, try to pack */ long unsigned int syscall_work; /* 40 8 */ struct cfi_status user_cfi_state; /* 48 32 */ /* --- cacheline 1 boundary (64 bytes) was 16 bytes ago --- */ long unsigned int a0; /* 80 8 */ long unsigned int a1; /* 88 8 */ long unsigned int a2; /* 96 8 */ /* size: 104, cachelines: 2, members: 10 */ /* sum members: 96, holes: 2, sum holes: 8 */ /* last cacheline: 40 bytes */ }; If we were to remove entire `cfi_status`, it would still be 72 bytes (88 bytes if shadow call stack were enabled) and already spans across two cachelines. I did see the comment above that it should fit inside a cacheline. Although I assumed its stale comment given that it already spans across cacheline and I didn't see any special mention in commit messages of changes which grew this structure above one cacheline. So I assumed this was a stale comment. On the other hand, whenever enable/lock bits are checked, there is a high likelyhood that user_ssp and other fields are going to be accessed and thus it actually might be helpful to have it all in one cacheline during runtime. So I am not sure if its helpful sticking to the comment which already is stale. > >> 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.) > >> csrr s2, CSR_EPC >> csrr s3, CSR_TVAL >> csrr s4, CSR_CAUSE >> @@ -236,6 +250,18 @@ SYM_CODE_START_NOALIGN(ret_from_exception) >> csrw CSR_SCRATCH, tp >> + >> + /* >> + * Going back to U mode, restore shadow stack pointer >> + */ > >Are we? I think we can be just as well returning back to kernel-space. >Similar to how we can enter the exception handler from kernel-space. > >> + ALTERNATIVE("nop; nop", >> + __stringify( \ >> + REG_L s3, TASK_TI_USER_SSP(tp); \ >> + csrw CSR_SSP, s3), >> + 0, >> + RISCV_ISA_EXT_ZICFISS, >> + CONFIG_RISCV_USER_CFI) >> + > >Thanks.