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 D5060C3601E for ; Thu, 10 Apr 2025 05:24:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 496972800CF; Thu, 10 Apr 2025 01:24:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 41B7D2800CE; Thu, 10 Apr 2025 01:24:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 296CE2800CF; Thu, 10 Apr 2025 01:24:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 06FA82800CE for ; Thu, 10 Apr 2025 01:24:09 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 60BFF161D7D for ; Thu, 10 Apr 2025 05:24:09 +0000 (UTC) X-FDA: 83316993018.03.88F053F Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by imf20.hostedemail.com (Postfix) with ESMTP id 71F021C0004 for ; Thu, 10 Apr 2025 05:24:07 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=Id8yUrBf; spf=pass (imf20.hostedemail.com: domain of debug@rivosinc.com designates 209.85.216.47 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=1744262647; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=PZYMzQXIXSU/bXW26sRzTu+9m/v0haq3s3VFwVwrb1s=; b=NJQBTxvsHKjqM0Q8AEpRx+tWOoTHEvZy+S1sKoxo28+b1Yd2iCflGQFMZOQrLqRQMeC6p3 3g6uf5bJ1Ar7xT0Rv0SGeC/HHRfHVPQSgTSKEN+YtFQ2wh93GiexJHtZDCdliSZtqndWOA eDVG3pMc5H3YWZBn4UrzzsUPM8eIeMc= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=Id8yUrBf; spf=pass (imf20.hostedemail.com: domain of debug@rivosinc.com designates 209.85.216.47 as permitted sender) smtp.mailfrom=debug@rivosinc.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744262647; a=rsa-sha256; cv=none; b=XTZUQPXb01l9H+dADGh0wIqy+C+TStq38For40+SGRCyIFxuzx5Oz1BDWoGybtmHS6zj+x NCjiVbJw/x0FOWWYXivsYFh86XsoM9bko3leXtGjjUqkog+e3nMyu6vOy+Rxx2jfqzx1aC Jras9RS0q6coJv0ZftYOjl1YfM2Qvww= Received: by mail-pj1-f47.google.com with SMTP id 98e67ed59e1d1-3014cb646ecso306418a91.1 for ; Wed, 09 Apr 2025 22:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1744262646; x=1744867446; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=PZYMzQXIXSU/bXW26sRzTu+9m/v0haq3s3VFwVwrb1s=; b=Id8yUrBfIQgj7DLIoHoQziWf29GNQ/vPzBhWbR5Oa4+EvNLIxyWinceP+XCQq0x1jH hQp3mzebo/PAfB4qznX/Dfk0tAx445EV+boVQxSGJmIxhHkwUhrKoryIU35N7kLdfU8D fkIdssXiOX8MBuj8ssqlAinHOrI2dX7cjQ3CEV7K2pm9ZktoJjmVYs498e2/T5+sOWE+ GrAEy+52vVbVO3WY6lRmfvf4TbQuOsFBYp5eHSvUq/17ac3pnwyeG9iJMyeHy3vvIiaZ 3PAis2yoo7hBSlrQ9TlxsIIBdKKyuzANEEYHY6LXLWpy8o/kbaG683C891bpl+gDXPzZ CrwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744262646; x=1744867446; h=in-reply-to: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=PZYMzQXIXSU/bXW26sRzTu+9m/v0haq3s3VFwVwrb1s=; b=uJIGWPC/n818mBGUKNglfnCsTz0ZAd4vaeyvi9tUbXwC98wLhSsRcsCSb+oRTFVDd0 YqVIiuP5yq8Spy+l8LZmU7Yz9TMTK774mK25bX+chxr5kXq9ovI8nMFp/SGR7nG0r3wE zC1aSo4+Ef48mHWEj63Om0y9yLqXz5x9NmIJBLh6cKyLUM+hr4VjXmseNFbKbcvpTDBo kZQOll10lfQ4gHBvBOym921O5+hEzs+xeyHwdUJM41Tzy7rH7wOwAFHRJ9SOjxbFr4ts uGm+zlOFVq53R2otTvJwivShEh+G0z56iXbOEtxyFhnggjLsxyd4ueIG08f7db9ZMwvQ gNRw== X-Forwarded-Encrypted: i=1; AJvYcCWBUs5MsLh9BUgQKsadHmVWubtHu0ehOFT/HObD5riO2mnzt0LrWuZ+7zb8XC0Iw5iqoR/VR7RvZg==@kvack.org X-Gm-Message-State: AOJu0YyYQLR9Ez/bEmldWqTrJ/1kEUirRs7LYtRigAHJQiGb5XZ2PITa QhHmkCkWgQGy1nwapE0CEq/Cmue7h4jhH72x/Y+P6J2BAUGFpItNTc3Y8CmyvvZEp/dhwXzYHoV j16E= X-Gm-Gg: ASbGncu1ezpd8O0Mb5fK9X96cx7YbPGVkf6tqEbyhOCzwGenIyjfh2t9AmEYx0iTRWL 2cvV9cxqLA7y7O9u1rzP5LAheTQjLuDI4HQJhc2Hcx/KeUv7AAaTR59uwDEjI17coE1KBvgzWMp OgCoFYvEm1/0Gz+EZFvWwMr9oLArBQKgehCQNmifBZDLVEmjSyTA5lSvDoOzfsgaCJvrLbRiOPy xoz2JYp34DkvFqyuBFxZQetYS+UNkm5T1IUwOOOWw1Gg8HHD72iRRWBmNljDjrASqrmaABTBsaC ejnVaHVpVWb/L29SuZfhjtkGlzn8Pqv3AQc06jNHuahlG4mhCys= X-Google-Smtp-Source: AGHT+IEFGYLi01GN6t1Qu8phsbyE3bnOEDBZkOiu+MAV/bjppeYPX1aHEWOs4wEGQPAvVv3qM4pyaQ== X-Received: by 2002:a17:90a:d64b:b0:2fa:13d9:39c with SMTP id 98e67ed59e1d1-30718b75cebmr2953474a91.14.1744262646173; Wed, 09 Apr 2025 22:24:06 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-22ac7ccac49sm21649615ad.217.2025.04.09.22.24.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Apr 2025 22:24:05 -0700 (PDT) Date: Wed, 9 Apr 2025 22:24:02 -0700 From: Deepak Gupta To: Alexandre Ghiti 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 Subject: Re: [PATCH v12 27/28] riscv: Documentation for shadow stack on riscv Message-ID: References: <20250314-v5_user_cfi_series-v12-0-e51202b53138@rivosinc.com> <20250314-v5_user_cfi_series-v12-27-e51202b53138@rivosinc.com> <2a24cc43-4150-4a56-ba09-0d136dde893f@ghiti.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <2a24cc43-4150-4a56-ba09-0d136dde893f@ghiti.fr> X-Rspamd-Queue-Id: 71F021C0004 X-Stat-Signature: srm3ubcms4p9io1m7zgwbhqwagdpcj4r X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1744262647-663487 X-HE-Meta: U2FsdGVkX18SwbkBtHMd75B3is/xkuyS4D8PKyadRVKMCdsemjoEqEiyF27kHUmyLhVrog2hPJLV4w0VdJsShKciqWY8Mg/REbPJE9+AFrJ9mUiuvu4o7UYnUvXDiGFiqeQMEhEQYrSDtca3RXDjYTG4HeeDm1FS9zQei8VnMypn/bpvGmfgoexx6ekMFpUkLcvCME+59I+4DnhB+1xzwud/iiq0+nfTR7Gxr/Ab6WxTUs+rzI/qgLvtXo5Sa5bMU/uxLcVnTAfKOBRRuawZyHcKKqMeKtIfUejGnqDojbGQlTC7JbhJ/BDlKQzknOzoTBnShWJjbGum4WMIykUj9Rj/tT30WK0eiRrxs61GC2AdZfQTM1lYqRZz37gBiZwyg1HDeVRcBkJXDZWZeigOy+iijnorXvvl0WlnyuK4UbmrSZCMKn5xHEQFZPUKrNMlklLUr3NC/X8lbAVVgkrVA43w+pI6HD2k2HnzjtxKtfdEKzRDmqII5K27RrJzorDL2aA84xsarOwVk7lYX/aP9ATyQyEh9UoiQd+VKocC4J1FIij+wKn1inYecyvfaKj8c1fHxp16Q9R3QmMnFkxNbtHpa93eb49BQEuMJhpll4KDw0IAaZ+uk0dj2aXVYdO8rbEZRsHa3mhMM7BE3HvOz2X1rpgcyPWRXqQl4jfOnFSznCXGJoVXG2OrxE9GLM6S+spRjwHhwgMwWkKE+SK6zeJLgUNC7gFX0xDbVhWLpKsMDAcbCRwIwQ8mpeBXk0ZoSWYtwOckNlLKHJfc+LZTEHWPp5zvkHd6yhihAFQEnvD3gyEnyDuG9M4W/luRK5FvK0AMY6hXIUj1+oyymjltBz6rKkY4ZhiCE/UnElWwB2xzGvFAWPqPokg2hspQtcbTttBnqlqJlYOIhyAkekijlFEKWmCH7pVEJRZOjlgK7Pz8rA3AiTGt6Yaug+x67tPy13NgzaqZletZxgIgdFT BSI9MP3c mR1pgcnOU+8kkO/Z99qgIh0IPRo/lx2lag+cRn1bOehUf73v4ybffcLCiuA0KPE1vbCEOEOx0F34L46RoX+TjTmvAx+aYDK2qVjxamxiEFbRVToP654P4NoGezeA44WmDexj9sGqsoHL3AJ/H6bYDn2eXD++KsiI1EUJT3DfldYVrmYXw/XjZbP/V8i+IupVpKr9LPxxk48g95aGvvB0oFqvToG9uercNsmxpY/nVoxVDN98rCAlKVVzz3QBjwIVk9HKDZOlGKzt5eLGVeDJCBq0xL24Ib5X8RZuCNf4uPeBlFDudpSkKtqKgRXfQSfCVO4tEg13470ntD4HcNIRDirgD4qXvxYWcREB18VY6oJSDOwmcbPMflOAMDhWk8z9w7SO95DSzetrGHAhhGGMY+vfC8bzUKq4bQ7OovUgqWjiEQjEjxjcBKt5fkDfH2JWnDj7AwkuwAZARpt50PkecVL25vTIlQkqB8r9SxQ94ItzhC2t8D1O4TYEHBD00/e/zw9a4D8RPJtM9B0eyDwnFmTqqibITqh7TUn+RxvfOiJAxSZwtUFAWFh1m/A== 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 Tue, Apr 08, 2025 at 10:48:08AM +0200, Alexandre Ghiti wrote: > >On 14/03/2025 22:39, Deepak Gupta wrote: >>Adding documentation on shadow stack for user mode on riscv and kernel >>interfaces exposed so that user tasks can enable it. >> >>Reviewed-by: Zong Li >>Signed-off-by: Deepak Gupta >>--- >> Documentation/arch/riscv/index.rst | 1 + >> Documentation/arch/riscv/zicfiss.rst | 176 +++++++++++++++++++++++++++++++++++ >> 2 files changed, 177 insertions(+) >> >>diff --git a/Documentation/arch/riscv/index.rst b/Documentation/arch/riscv/index.rst >>index be7237b69682..e240eb0ceb70 100644 >>--- a/Documentation/arch/riscv/index.rst >>+++ b/Documentation/arch/riscv/index.rst >>@@ -15,6 +15,7 @@ RISC-V architecture >> vector >> cmodx >> zicfilp >>+ zicfiss >> features >>diff --git a/Documentation/arch/riscv/zicfiss.rst b/Documentation/arch/riscv/zicfiss.rst >>new file mode 100644 >>index 000000000000..5ba389f15b3f >>--- /dev/null >>+++ b/Documentation/arch/riscv/zicfiss.rst >>@@ -0,0 +1,176 @@ >>+.. SPDX-License-Identifier: GPL-2.0 >>+ >>+:Author: Deepak Gupta >>+:Date: 12 January 2024 >>+ >>+========================================================= >>+Shadow stack to protect function returns on RISC-V Linux >>+========================================================= <... snipped ..> >>+ >>+5. violations related to returns with shadow stack enabled >>+----------------------------------------------------------- >>+ >>+Pertaining to shadow stack, CPU raises software check exception in following >>+condition: >>+ >>+- On execution of ``sspopchk x1/x5``, ``x1/x5`` didn't match top of shadow >>+ stack. If mismatch happens then cpu does ``*tval = 3`` and raise software >>+ check exception. >>+ >>+Linux kernel will treat this as :c:macro:`SIGSEV`` with code = >>+:c:macro:`SEGV_CPERR` and follow normal course of signal delivery. >>+ >>+6. Shadow stack tokens >>+----------------------- >>+Regular stores on shadow stacks are not allowed and thus can't be tampered >>+with via arbitrary stray writes due to bugs. Method of pivoting / switching to >>+shadow stack is simply writing to csr ``CSR_SSP`` changes active shadow stack. > > >I don't understand the end of this sentence. I'll rephrase it to make it readable and understandable. > > >>+This can be problematic because usually value to be written to ``CSR_SSP`` will >>+be loaded somewhere in writeable memory and thus allows an adversary to >>+corruption bug in software to pivot to an any address in shadow stack range. > > >Remove "an" > > >>+Shadow stack tokens can help mitigate this problem by making sure that: >>+ >>+- When software is switching away from a shadow stack, shadow stack pointer >>+ should be saved on shadow stack itself and call it ``shadow stack token`` >>+ >>+- When software is switching to a shadow stack, it should read the >>+ ``shadow stack token`` from shadow stack pointer and verify that >>+ ``shadow stack token`` itself is pointer to shadow stack itself. >>+ >>+- Once the token verification is done, software can perform the write to >>+ ``CSR_SSP`` to switch shadow stack. >>+ >>+Here software can be user mode task runtime itself which is managing various >>+contexts as part of single thread. Software can be kernel as well when kernel >>+has to deliver a signal to user task and must save shadow stack pointer. Kernel >>+can perform similar procedure by saving a token on user shadow stack itself. >>+This way whenever :c:macro:`sigreturn` happens, kernel can read the token and >>+verify the token and then switch to shadow stack. Using this mechanism, kernel >>+helps user task so that any corruption issue in user task is not exploited by >>+adversary by arbitrarily using :c:macro:`sigreturn`. Adversary will have to >>+make sure that there is a ``shadow stack token`` in addition to invoking >>+:c:macro:`sigreturn` >>+ >>+7. Signal shadow stack >>+----------------------- >>+Following structure has been added to sigcontext for RISC-V:: >>+ >>+ struct __sc_riscv_cfi_state { >>+ unsigned long ss_ptr; >>+ }; >>+ >>+As part of signal delivery, shadow stack token is saved on current shadow stack >>+itself and updated pointer is saved away in :c:macro:`ss_ptr` field in >>+:c:macro:`__sc_riscv_cfi_state` under :c:macro:`sigcontext`. Existing shadow >>+stack allocation is used for signal delivery. During :c:macro:`sigreturn`, >>+kernel will obtain :c:macro:`ss_ptr` from :c:macro:`sigcontext` and verify the >>+saved token on shadow stack itself and switch shadow stack. >>