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 B8942C282EC for ; Fri, 14 Mar 2025 08:34:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9C2B128000F; Fri, 14 Mar 2025 04:34:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 972B1280001; Fri, 14 Mar 2025 04:34:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8156A28000F; Fri, 14 Mar 2025 04:34:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 62C24280001 for ; Fri, 14 Mar 2025 04:34:24 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id BA1B8140CAB for ; Fri, 14 Mar 2025 08:34:24 +0000 (UTC) X-FDA: 83219494848.27.D170C4F Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) by imf01.hostedemail.com (Postfix) with ESMTP id AF4784000A for ; Fri, 14 Mar 2025 08:34:22 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=sifive.com header.s=google header.b=aHMJOhTp; spf=pass (imf01.hostedemail.com: domain of zong.li@sifive.com designates 209.85.166.53 as permitted sender) smtp.mailfrom=zong.li@sifive.com; dmarc=pass (policy=reject) header.from=sifive.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741941262; 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=6iX3HNdGAyavSd81H2hduaaeN8aF6ISRjVvfsb1XI+c=; b=z8HCRHLCWeIVEO2rgJG2CD37z6SM6TwEAVDv2AscYURuACkOcqZB5I4RKzhWpWDOueBE31 IFydADCIxGem3fcTb20wLm3Rliw95Spsy8zMUfAVI5ECDmnu7ig1uGA7wmZepbxtUUSYxs mXqcW1VPgdR2gkgI/NDaJ4+JtNII8Wo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741941262; a=rsa-sha256; cv=none; b=YVf87ANk1IxSi8tsff31mJDnEtWikA/CNnXRyN5Wib7ahCVoxQuXrlOIoOIe9c9jbMnGcy +AOQTyQPD1oNw6llrijdY+oECcrWdfULBS8FUO3AiL/qiqBE45VOFoN6/d5mKTUfTbIF4S ofZXSaHb/ZUvKSVLRjU+BlJ61UWzKZU= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=sifive.com header.s=google header.b=aHMJOhTp; spf=pass (imf01.hostedemail.com: domain of zong.li@sifive.com designates 209.85.166.53 as permitted sender) smtp.mailfrom=zong.li@sifive.com; dmarc=pass (policy=reject) header.from=sifive.com Received: by mail-io1-f53.google.com with SMTP id ca18e2360f4ac-85db872dd80so40595839f.0 for ; Fri, 14 Mar 2025 01:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1741941262; x=1742546062; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=6iX3HNdGAyavSd81H2hduaaeN8aF6ISRjVvfsb1XI+c=; b=aHMJOhTpaW5qDYSh8lJURxn6fSnru4q83ttIII5uSFBFNyTwgvm4OVN2/+w/039BTH jH6TnF6NQwC0z8lhUgBAX+SAZRRUZkCOU7SMTXodGg+ePIn405LcXBpu5sKox9kxZZee fFZwvALMV6t42q/hcJdlpNvN8ZZICkxEaayuQN5vh2Q24Phc77VlFMsFwi+ewc1G/lR7 uwIRBm0XeaQSHQPplnBXkabJyM5OGVViHAi5/jAbLXwc+8OeCs0F74n2m54vO8UFm6yJ 2ZSESS7lVaz1EpLBIHUEdR7egBzEJGm6JYYjXfiHtmYU4ibuu8+uRKhxPPn6uWAWTTZP BUYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741941262; x=1742546062; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=6iX3HNdGAyavSd81H2hduaaeN8aF6ISRjVvfsb1XI+c=; b=NYtYPKbT7ll/14RpCghkHqIk8T7CV7ALZ2eKP35ukzymY+wbPYrIlLh9KLfkLeUcWQ VSfpI4varVwD7JwStl8H1qrMa6MxxO9PW+79bANOq3xVcY6Fp4zle+6dnAat00Ezpdv2 qtZuhxUVOkltS1VsNMWeHeiHL9QikFQ2dF8m96jnEt9Lnz9otlWFytf3S7Jd3/4cl4hm viUDV17HiN303j25MTcNyH+gyidnIcFAxd3JvCIKGL0DEqKgpPV+ZbBcekU67nNbUiA4 9iU8wVFnz1QFx3FaOi2hP2lyqfs6XJ1q7yCBLfYFlcQ5me+mKlKcLkE8PTw3nzzGs4K2 MVhA== X-Forwarded-Encrypted: i=1; AJvYcCWHOaXzUFL4E/dTi3cYXLiP/0fCNPIb/UfV1I7fmdZvBUXYPxpdC7NxY8aSjpQNwgjmCVbU7QnL8w==@kvack.org X-Gm-Message-State: AOJu0Yws5avXLg90Ao2ocfpVg7NEXJ5t3s8qUK5QURWv14c0HAsi1mLr YcBVKthS/GCXG8TNm0fNjON0XI0V6gtEz6R3hftUaPENTiJaqZ03xyHXqcMdsh8WJESBwSgYLtr FdwfsGwSrXEeJp7qn1a2zslJfYStc2R7a35Y+cQ== X-Gm-Gg: ASbGncvnEZesrx1jE9Oj2hzpWSEN8t4ByQCJ+7aPRcTg0BMtXjc85/x/zOdWmgvvYni MRFYL+SWtpg+5OWI70H7fEDrI5F6EtrBz4tsBD0HIozjUQDY63Jiv/7EXzltMWPtj4spZ/4MqAL ALAKYMvinIJATbj/menoGSzws4ikI= X-Google-Smtp-Source: AGHT+IFME8iCFHQ4xqD2/WWFrTRPOU1/5Sslq5ZEgutz88HkOy5WNMIQDAQr6rDnrqf7KpiIgv+a/574qkZnFTRQaKQ= X-Received: by 2002:a92:c264:0:b0:3d3:f775:cec0 with SMTP id e9e14a558f8ab-3d483a8a586mr13610575ab.22.1741941261616; Fri, 14 Mar 2025 01:34:21 -0700 (PDT) MIME-Version: 1.0 References: <20250310-v5_user_cfi_series-v11-0-86b36cbfb910@rivosinc.com> <20250310-v5_user_cfi_series-v11-26-86b36cbfb910@rivosinc.com> In-Reply-To: <20250310-v5_user_cfi_series-v11-26-86b36cbfb910@rivosinc.com> From: Zong Li Date: Fri, 14 Mar 2025 16:34:09 +0800 X-Gm-Features: AQ5f1Jp8Q3U18WuKV3ZW8T-JMN0pM5rQRGCfXRWh0Hd6bXSFmFWjBm-HCCbZo7Q Message-ID: Subject: Re: [PATCH v11 26/27] riscv: Documentation for shadow stack on riscv To: Deepak Gupta 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: AF4784000A X-Stat-Signature: c9xhyqiw1y4qf6fss8e4xg3t74e1bw1m X-HE-Tag: 1741941262-458784 X-HE-Meta: U2FsdGVkX180FsdBw0b3qeSFrl8Dufj6hA/TebNscxvxzJPSwyoUQyg2Epd5Vs8laYaD5tj9xFs9QctjgIZ17v1f8V4hDgnsUyAcW8vLOUw4ENH4H30b0utIbdPKbHTh7e3LH8Ltxgs+C+gdsAlmWYsQ20GrY9ihX9wKTf7MnMs1yp6l0iQ00939Z1V6XaRNR8sQqadqMjSD/XXmq025PnppDbzaH2vvC2JWHCyBm32Szlzo5FJwCPDSnbxm+0x+hIaVfs7k7j1BzbwKxkoonUkc4NWQs5KY8m0RlaA99V6Jgky0pjkXcQSGFN8vbzTXyxNz0NGvWygQww6FAmnoc0s2o6HUROQenoZofFMJpTqaN4vxt/vjkitFsx22FFeg8zBe9rxzQtfWa5D+G5tq4I6dv33BTzvVU2Ua1kLoY5/IQvKUqIQ0b+6ioLCyLFgccIQOo9hBerT7rB+iTVQlaVdgazJZOXs9xYQa4g64OfE4qVXHqRXGXIVDRGFqPEC0tF8vXzYmNmDsM4T00wYgOSbjsxNV3JuCqv77Ag6f2otMnPnVmvay2Q23fTyatsy8+Qmx4oxha4VkgoUOUco6edJiWftjLiewNy/KU51pV1WzbgLEQ4K4eCuuFZHEPa1YwQJdf167J3Td4dxvbTbDT/QTKLwjPgqNmkfV8vgLbVnXRjiOYYElZyF6NuCPSHrmAt0fPK9wivCK8urwUIYgBQx7KSTU7pi4H/JpdHvb+pEQRYPKmzNYF6BRIi+NHq8PuuAzV0oxy2lpupIHwwdrddi5XtP41Ns1s9bT80foPXxVpkyLzPWN2JtWraOSMyC1TDkIu3+B2bizlJTgOHsjtoDBAQBI3jHS2w91AD+wYziw+G3/7wsyLcJTn1WxfadItDsOziUjqQOp7NywkAXOogR0yCOZippWpkCe+xRIJ06hpng79iau2YtZR6+GOZ2Hv+F8A0nOmRmKr8NAhk2 KZ0bgzsY I+5a+ZnK++0+DOw6Ebl8WY6tqESbHKljIihzDYgspG8lEheGy8C01SNszJWinbDJzOnPrRAWUrjg06K0ABZ197UYPXNsaETembtLIs4lGoxarW9u8H47cnQRDuUVRgtXuOgG1UBaSQQJV5QSWiCODn1iDK/notOf73pZer7w6V5UGeNca2S28NpWTNZ4Rvfrxw987EnSo/JqdhelMKo81osI1eKgXnDEN3qYZNKpQqdguOuOZ+qdAmi9YOD9K7cZr7tCu7OE9BHXAwpqisKoin0mIM1H6ze67iiYpNj6Ef2DcBvEfHZLrPwxZ6pRIDCk1YdKe0q/fcRVH1pOCbtgZ/XJQJ2bz9yz0LHdu8r2KTxvGs91/5xE5u6tomSLmCBz5pns7I+FBX7nGjWcfRD2M5jIR8JUCsxy4+ntq98Woxu+okcY+ydyhJqoSLBJLAGsPPuky 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 Mon, Mar 10, 2025 at 11:44=E2=80=AFPM Deepak Gupta = wrote: > > Adding documentation on shadow stack for user mode on riscv and kernel > interfaces exposed so that user tasks can enable it. > > 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/risc= v/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/ri= scv/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 > + > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > +Shadow stack to protect function returns on RISC-V Linux > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > + > +This document briefly describes the interface provided to userspace by L= inux > +to enable shadow stack for user mode applications on RISV-V > + > +1. Feature Overview > +-------------------- > + > +Memory corruption issues usually result in to crashes, however when in h= ands of > +an adversary and if used creatively can result into variety security iss= ues. > + > +One of those security issues can be code re-use attacks on program where > +adversary can use corrupt return addresses present on stack and chain th= em > +together to perform return oriented programming (ROP) and thus compromis= ing > +control flow integrity (CFI) of the program. > + > +Return addresses live on stack and thus in read-write memory and thus ar= e > +susceptible to corruption and allows an adversary to reach any program c= ounter > +(PC) in address space. On RISC-V ``zicfiss`` extension provides an alter= nate > +stack termed as shadow stack on which return addresses can be safely pla= ced in > +prolog of the function and retrieved in epilog. ``zicfiss`` extension ma= kes > +following changes: > + > +- PTE encodings for shadow stack virtual memory > + An earlier reserved encoding in first stage translation i.e. > + PTE.R=3D0, PTE.W=3D1, PTE.X=3D0 becomes PTE encoding for shadow stack= pages. > + > +- ``sspush x1/x5`` instruction pushes (stores) ``x1/x5`` to shadow stack= . > + > +- ``sspopchk x1/x5`` instruction pops (loads) from shadow stack and comp= ares > + with ``x1/x5`` and if un-equal, CPU raises ``software check exception`= ` with > + ``*tval =3D 3`` > + > +Compiler toolchain makes sure that function prologue have ``sspush x1/x5= `` to > +save return address on shadow stack in addition to regular stack. Simila= rly > +function epilogs have ``ld x5, offset(x2)`` followed by ``sspopchk x5`` = to > +ensure that popped value from regular stack matches with popped value fr= om > +shadow stack. > + > +2. Shadow stack protections and linux memory manager > +----------------------------------------------------- > + > +As mentioned earlier, shadow stack get new page table encodings and thus= have > +some special properties assigned to them and instructions that operate o= n them > +as below: > + > +- Regular stores to shadow stack memory raises access store faults. This= way > + shadow stack memory is protected from stray inadvertant writes. > + > +- Regular loads to shadow stack memory are allowed. This allows stack tr= ace > + utilities or backtrace functions to read true callstack (not tampered)= . > + > +- Only shadow stack instructions can generate shadow stack load or shado= w stack > + store. > + > +- Shadow stack load / shadow stack store on read-only memory raises AMO/= store > + page fault. Thus both ``sspush x1/x5`` and ``sspopchk x1/x5`` will rai= se AMO/ > + store page fault. This simplies COW handling in kernel During fork, ke= rnel > + can convert shadow stack pages into read-only memory (as it does for r= egular > + read-write memory) and as soon as subsequent ``sspush`` or ``sspopchk`= ` in > + userspace is encountered, then kernel can perform COW. > + > +- Shadow stack load / shadow stack store on read-write, read-write-execu= te > + memory raises an access fault. This is a fatal condition because shado= w stack > + should never be operating on read-write, read-write-execute memory. > + > +3. ELF and psABI > +----------------- > + > +Toolchain sets up :c:macro:`GNU_PROPERTY_RISCV_FEATURE_1_BCFI` for prope= rty > +:c:macro:`GNU_PROPERTY_RISCV_FEATURE_1_AND` in notes section of the obje= ct file. > + > +4. Linux enabling > +------------------ > + > +User space programs can have multiple shared objects loaded in its addre= ss space > +and it's a difficult task to make sure all the dependencies have been co= mpiled > +with support of shadow stack. Thus it's left to dynamic loader to enable > +shadow stack for the program. > + > +5. prctl() enabling > +-------------------- > + > +:c:macro:`PR_SET_SHADOW_STACK_STATUS` / :c:macro:`PR_GET_SHADOW_STACK_ST= ATUS` / > +:c:macro:`PR_LOCK_SHADOW_STACK_STATUS` are three prctls added to manage = shadow > +stack enabling for tasks. prctls are arch agnostic and returns -EINVAL o= n other > +arches. > + > +* prctl(PR_SET_SHADOW_STACK_STATUS, unsigned long arg) > + > +If arg1 :c:macro:`PR_SHADOW_STACK_ENABLE` and if CPU supports ``zicfiss`= ` then > +kernel will enable shadow stack for the task. Dynamic loader can issue t= his > +:c:macro:`prctl` once it has determined that all the objects loaded in a= ddress > +space have support for shadow stack. Additionally if there is a > +:c:macro:`dlopen` to an object which wasn't compiled with ``zicfiss``, d= ynamic > +loader can issue this prctl with arg1 set to 0 (i.e. > +:c:macro:`PR_SHADOW_STACK_ENABLE` being clear) > + > +* prctl(PR_GET_SHADOW_STACK_STATUS, unsigned long *arg) > + > +Returns current status of indirect branch tracking. If enabled it'll ret= urn > +:c:macro:`PR_SHADOW_STACK_ENABLE`. > + > +* prctl(PR_LOCK_SHADOW_STACK_STATUS, unsigned long arg) > + > +Locks current status of shadow stack enabling on the task. User space ma= y want > +to run with strict security posture and wouldn't want loading of objects > +without ``zicfiss`` support in it and thus would want to disallow disabl= ing of > +shadow stack on current task. In that case user space can use this prctl= to > +lock current settings. > + > +5. violations related to returns with shadow stack enabled > +----------------------------------------------------------- > + > +Pertaining to shadow stack, CPU raises software check exception in follo= wing > +condition: > + > +- On execution of ``sspopchk x1/x5``, ``x1/x5`` didn't match top of shad= ow > + stack. If mismatch happens then cpu does ``*tval =3D 3`` and raise sof= tware > + check exception. > + > +Linux kernel will treat this as :c:macro:`SIGSEV`` with code =3D > +: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 tamper= ed > +with via arbitrary stray writes due to bugs. Method of pivoting / switch= ing to > +shadow stack is simply writing to csr ``CSR_SSP`` changes active shadow = stack. > +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 ra= nge. > +Shadow stack tokens can help mitigate this problem by making sure that: > + > +- When software is switching away from a shadow stack, shadow stack poin= ter > + should be saved on shadow stack itself and call it ``shadow stack toke= n`` > + > +- 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 var= ious > +contexts as part of single thread. Software can be kernel as well when k= ernel > +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 its= elf. > +This way whenever :c:macro:`sigreturn` happens, kernel can read the toke= n 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 exploit= ed 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 shado= w 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 sh= adow > +stack allocation is used for signal delivery. During :c:macro:`sigreturn= `, > +kernel will obtain :c:macro:`ss_ptr` from :c:macro:`sigcontext` and veri= fy the > +saved token on shadow stack itself and switch shadow stack. > LGTM. Reviewed-by: Zong Li > -- > 2.34.1 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv