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 B52EDC3ABCB for ; Mon, 16 Sep 2024 03:20:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 40B8D6B0089; Sun, 15 Sep 2024 23:20:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 391B06B008A; Sun, 15 Sep 2024 23:20:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 198466B008C; Sun, 15 Sep 2024 23:20:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E6E756B0089 for ; Sun, 15 Sep 2024 23:20:55 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 6AD991A01EC for ; Mon, 16 Sep 2024 03:20:55 +0000 (UTC) X-FDA: 82569149670.11.5A0E13B Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by imf07.hostedemail.com (Postfix) with ESMTP id 6D0314000A for ; Mon, 16 Sep 2024 03:20:52 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lK45nMXo; spf=pass (imf07.hostedemail.com: domain of bagasdotme@gmail.com designates 209.85.214.173 as permitted sender) smtp.mailfrom=bagasdotme@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726456744; 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=Ln43YramaFeXVEywvFE+ekQsGy0RBkrTNESqwuctvu0=; b=ceia3IZpZQSe/tGo5LUpYU6CAjStIkNlGwcfmPJJd8tlRlm/YWdhanKTMdgQnB8hZMnC2T U9eV43n/AXDccM4EkKjDMBVwI3M1lYGBHG0ysSWw3O/hFlJEuZ6r5hr6S2Rbf//Xl/fAw2 P6/gPWBI9U9wXYdb45u1zn7s+O4iidM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726456744; a=rsa-sha256; cv=none; b=b7045ma8sRK/14LIefU45+zl4hj6zN8Nk21gbbsshyIgo7//JUezC3iA6lMxJq7It0bhtL 59HXZOXWGhzwlQxUOSG87FKcLv/s25WBgDRepLRUbPV0zqtlnK6lCjMHbm5926DUeRwAzX f7u0KYSPSqbnU/RHczGL2A52/ZBgZOE= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lK45nMXo; spf=pass (imf07.hostedemail.com: domain of bagasdotme@gmail.com designates 209.85.214.173 as permitted sender) smtp.mailfrom=bagasdotme@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-206e614953aso39626195ad.1 for ; Sun, 15 Sep 2024 20:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726456851; x=1727061651; 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=Ln43YramaFeXVEywvFE+ekQsGy0RBkrTNESqwuctvu0=; b=lK45nMXol6+Jh0+0EeVngjwORPCaWdQKt9/iTDgzGARnHJUXl1hoC83px6P8k49980 Gcz6y0PYUC0xbH+E38A036RlOZMJE1IwS87gWEa0gTMFTZEUj+SjasagEv2yyhAIQGUf w/A/iY6DJro92k9X+hgcwmT63XlfU8TG1MqctAB8V3ZnyqQccCbDkHawfIeXUo8+/r/3 A9EjPrmJ3fwA4BPBnD1UM5+MMGsN7Yj1+nTUvZQufaLwRnYU2KmGLNlyl3Kjs/qke4z5 rxuqwMw9smyceCSor9u3J4mZ77Rzc5kDECkt4GHHe+0NnBxFOK4yq7x6RkF2zYMTr8E/ 9Ttw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726456851; x=1727061651; 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=Ln43YramaFeXVEywvFE+ekQsGy0RBkrTNESqwuctvu0=; b=uAPko36PGVO9DlYw+FKLauDcjj4+7dW8V3e5XzLjIZ2554GGA2IVH5eW20PXwdLfj8 /6xJY8/MYllD04zUlKWFkicEmHLpou4fb2ruTkZjhAhWK7IhnJShSokcCxYsnHnXv4lK KExcBBHFsbxziZnmnDCHnz8iE970q1q5IP0cg4VC8L+krsogj9K3nHKtrT6uuQeEdLyu 891V2022iJquplAsdm7BEfncO8lf++UZ1/+Zn65nwYuPJHmwffydWmPxiK3UX+Twrh/t lIfPu3AN4eM/hvlX/4u7WtRZJXlVe/SxFy2lXkHJwz7yQpwUDajbV397F7hlX7Jj6+Nt Uk9w== X-Forwarded-Encrypted: i=1; AJvYcCU8hmgEo8SoqYBFejPXPyG6C564Uo3RR965+SHXufB+pFmrxRwsOHVW3thLKlVeI0NRLvrmBWP6mQ==@kvack.org X-Gm-Message-State: AOJu0YweFp8VIJ4o1lOQKbuMbMvH8PnFQtSECJOXTGp3ARBBmQnXFIJp k+Cv0nIuk01tLbbQtLHVDqj4eUJxkIK872Oy4zUQ/iEFYiHQG/Ed X-Google-Smtp-Source: AGHT+IFA89uF5dUq73MmeIgJ/Ku23WBy9As54dvHWaFbWcJKhaq1OuaHwUPbzvXCjHE2C1SrWA+1bw== X-Received: by 2002:a17:903:1d0:b0:207:60f4:a393 with SMTP id d9443c01a7336-2076e3939f5mr173378345ad.27.1726456850754; Sun, 15 Sep 2024 20:20:50 -0700 (PDT) Received: from archie.me ([103.124.138.155]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-207946d19c0sm28405525ad.146.2024.09.15.20.20.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Sep 2024 20:20:50 -0700 (PDT) Received: by archie.me (Postfix, from userid 1000) id 279664A358AE; Mon, 16 Sep 2024 10:20:46 +0700 (WIB) Date: Mon, 16 Sep 2024 10:20:46 +0700 From: Bagas Sanjaya To: Deepak Gupta , paul.walmsley@sifive.com, palmer@sifive.com, conor@kernel.org, linux-doc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kselftest@vger.kernel.org Cc: corbet@lwn.net, palmer@dabbelt.com, aou@eecs.berkeley.edu, robh@kernel.org, krzk+dt@kernel.org, oleg@redhat.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, peterz@infradead.org, akpm@linux-foundation.org, arnd@arndb.de, ebiederm@xmission.com, kees@kernel.org, Liam.Howlett@oracle.com, vbabka@suse.cz, lorenzo.stoakes@oracle.com, shuah@kernel.org, brauner@kernel.org, samuel.holland@sifive.com, andy.chiu@sifive.com, jerry.shih@sifive.com, greentime.hu@sifive.com, charlie@rivosinc.com, evan@rivosinc.com, cleger@rivosinc.com, xiao.w.wang@intel.com, ajones@ventanamicro.com, anup@brainfault.org, mchitale@ventanamicro.com, atishp@rivosinc.com, sameo@rivosinc.com, bjorn@rivosinc.com, alexghiti@rivosinc.com, david@redhat.com, libang.li@antgroup.com, jszhang@kernel.org, leobras@redhat.com, guoren@kernel.org, samitolvanen@google.com, songshuaishuai@tinylab.org, costa.shul@redhat.com, bhe@redhat.com, zong.li@sifive.com, puranjay@kernel.org, namcaov@gmail.com, antonb@tenstorrent.com, sorear@fastmail.com, quic_bjorande@quicinc.com, ancientmodern4@gmail.com, ben.dooks@codethink.co.uk, quic_zhonhan@quicinc.com, cuiyunhui@bytedance.com, yang.lee@linux.alibaba.com, ke.zhao@shingroup.cn, sunilvl@ventanamicro.com, tanzhasanwork@gmail.com, schwab@suse.de, dawei.li@shingroup.cn, rppt@kernel.org, willy@infradead.org, usama.anjum@collabora.com, osalvador@suse.de, ryan.roberts@arm.com, andrii@kernel.org, alx@kernel.org, catalin.marinas@arm.com, broonie@kernel.org, revest@chromium.org, bgray@linux.ibm.com, deller@gmx.de, zev@bewilderbeest.net Subject: Re: [PATCH v4 29/30] riscv: Documentation for shadow stack on riscv Message-ID: References: <20240912231650.3740732-1-debug@rivosinc.com> <20240912231650.3740732-30-debug@rivosinc.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cfhcWBhyYL8bTXY7" Content-Disposition: inline In-Reply-To: <20240912231650.3740732-30-debug@rivosinc.com> X-Rspamd-Queue-Id: 6D0314000A X-Stat-Signature: qgfycb1q5fmci6nhy53jr1si3qi8a4j1 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1726456852-539997 X-HE-Meta: U2FsdGVkX1+W+BS7eFnzIL0wQnS8KDdEwwWGDVdkuzckv+Xnt6mT6B+3mTi9DNme+n3jtzAjcN3glrXkmIntM/l1Jmih5jbOYOBaHWouJkmlfHhKRHfWecC9wHpLqhy6FZMch+49j/S7G5qxGrW3tvrWHM4JaEf/D4DXrbSfOOCx1Zw+9+Tr3sdldt4bp/Nht6LB50DzvjJ+xMdeKgdVApxfA6gYTUyQHDUgxlLYbDskNYgurZnMc2H06hj1G2VLtmAPLhUHw2wZjX17PHkBimYycRRFRqjvLhFM6VUWdS2JOHcaZGcUjTO8Da7KI8qodCRpdkkr7Zx1hjj1WmyPCH8QzlfuopRMQhXJdhoXfjPOLhQUATX0uuKgYDPUc1PuME4XBE6tvAYsRaOBAEV1sGUSBdsSXaxDJL2xZiYM9YXAgMuBzlv9lQrjlhTqLGZ3N7xKUntGvkRYyygExTsqoeTilcK3p4suGEaCkDYq7yV1UjoBGyYSuroWpqj5eDfiSDGwypDM8XX3OvGOJ11aDfPbkNZWFlKSFWTnz0pLR8+qhuTDekfXAG5kj5h+Pbakwl0xhOAoEwb/qTMeHm6wROo5c8j5TuGSQ6P5vZ+xUNG5TYL1/5smfSXIOnwZSs34YAKRmZJ1vvQK0oJodMBaqaRQK8icfEqcY/Lh6Wqfuuy3mYQabPHMT1UOa9S/nTvFZuYMdGJHg0PzjDLb2xwoBDzRpbvcHmH7OLdDgu55lxWy3KugVernMdRXSZRgu6NTAstHwiNydWdyGZAJ9J4+0WqgitU9QXYkB91oFgQj2gOSPlyU0J2vemQZx8yqwErW2sJkpiqdC+gs3hwjh2rMXJ0sUhchAjFfwQqnWOK+reHXbTB23CSL8DVOiksKq2trf5eqKtQwA5krDFW7XdpLXhFGFxzM1/fJD1IALuJ09MIIm0pGTyJLI/h8mhIrrkjsOIFBDY/FAMTm2zQD0Mm +n6foCwJ KpqvBs6Jxl/kzqGvsvvsgOqj6s7YMGa47vL31Z7D+vdzhuczF09ZDPyRyt4OSmEqdJ0Z5wqWwXuuTcWMItR7/3tV1ueASx89+EAJ0asBnJh0ZZhV+DJvCMmjDOxCoa7PZDXC2SwT2qWN0Uiq5eV46aNsftWQANHLmpYYRra7eDjHnT1xDrdiHYaligho8u37dRCGlULIAgVReZgEym6CySGeAUDk5+dzmahqTExQhgcndhgfgk7RDxE3/FavtZuVrQQQsXQx1EroB7qmv3L58J45ji2a77i6EKfRbMFNBA+oDk5eCattnc1H2mto9ixo4h/az7635B7t2cDLfLp/tMtdc9db+sJ53G8FlFIb6DM95wK+VKXrpSGkp+QIZIpKeVUJUWxYpAjg1NBWIWsfXuLKoYTXhZJMmLXpQ1RRwKK3R5cWTIjicsUkk+QRKso+AUwoxMnzl2dHQvH2d1P8WguMqRb/nB2dyHwdcTPS9Klk3rEW2lQxDQvr5WIHybMo4o+tbM4ft+W8ZgO9Abvkpxx3jTSDOCIuzh/yDQlJwZJTNYpGUOO55Q5ZoLSX7MdaBFObLuiZ3Xf16h/ZlP/IyJPPyN08aX3N3NA8pH9mTJYBHpDQ= 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: --cfhcWBhyYL8bTXY7 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 12, 2024 at 04:16:48PM -0700, Deepak Gupta wrote: > Adding documentation on shadow stack for user mode on riscv and kernel > interfaces exposed so that user tasks can enable it. >=20 > Signed-off-by: Deepak Gupta > --- > Documentation/arch/riscv/zicfiss.rst | 169 +++++++++++++++++++++++++++ > 1 file changed, 169 insertions(+) > create mode 100644 Documentation/arch/riscv/zicfiss.rst Add the toctree entry: ---- >8 ---- diff --git a/Documentation/arch/riscv/index.rst b/Documentation/arch/riscv/= index.rst index be7237b6968213..e240eb0ceb70c4 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 > +Following structure has been added to sigcontext for RISC-V. `rsvd` fiel= d has been kept > +in case we need some extra information in future for landing pads / indi= rect branch > +tracking. It has been kept today in order to allow backward compatibilit= y in future. > + > +struct __sc_riscv_cfi_state { > + unsigned long ss_ptr; > + unsigned long rsvd; > +}; Sphinx reports indentation warning again: Documentation/arch/riscv/zicfiss.rst:163: WARNING: Definition list ends wit= hout a blank line; unexpected unindent. I have to wrap __sc_riscv_cfi_state struct definition as a literal code blo= ck: ---- >8 ---- diff --git a/Documentation/arch/riscv/zicfiss.rst b/Documentation/arch/risc= v/zicfiss.rst index f133b6af9c1525..96d85ed352b146 100644 --- a/Documentation/arch/riscv/zicfiss.rst +++ b/Documentation/arch/riscv/zicfiss.rst @@ -155,12 +155,12 @@ make sure that there is a `shadow stack token` in add= ition to invoking `sigretur ----------------------- Following structure has been added to sigcontext for RISC-V. `rsvd` field = has been kept in case we need some extra information in future for landing pads / indire= ct branch -tracking. It has been kept today in order to allow backward compatibility = in future. +tracking. It has been kept today in order to allow backward compatibility = in future:: -struct __sc_riscv_cfi_state { + struct __sc_riscv_cfi_state { unsigned long ss_ptr; unsigned long rsvd; -}; + }; As part of signal delivery, shadow stack token is saved on current shadow = stack itself and updated pointer is saved away in `ss_ptr` field in `__sc_riscv_cfi_state` = under `sigcontext` > + > +As part of signal delivery, shadow stack token is saved on current shado= w stack itself and > +updated pointer is saved away in `ss_ptr` field in `__sc_riscv_cfi_state= ` under `sigcontext` > +Existing shadow stack allocation is used for signal delivery. During `si= greturn`, kernel will > +obtain `ss_ptr` from `sigcontext` and verify the saved token on shadow s= tack itself and switch > +shadow stack. Also inline the code identifiers (keywords): ---- >8 ---- diff --git a/Documentation/arch/riscv/zicfiss.rst b/Documentation/arch/risc= v/zicfiss.rst index 96d85ed352b146..9f721fbcaa6f6a 100644 --- a/Documentation/arch/riscv/zicfiss.rst +++ b/Documentation/arch/riscv/zicfiss.rst @@ -23,30 +23,30 @@ of the program. Return addresses live on stack and thus in read-write memory and thus are susceptible to corruption and allows an adversary to reach any program cou= nter -(PC) in address space. On RISC-V `zicfiss` extension provides an alternate= stack -`shadow stack` on which return addresses can be safely placed in prolog of= the -function and retrieved in epilog. `zicfiss` extension makes following chan= ges +(PC) in address space. On RISC-V ``zicfiss`` extension provides an alterna= te stack +(`shadow stack`) on which return addresses can be safely placed in prolog = of the +function and retrieved in epilog. ``zicfiss`` extension makes following ch= anges: - 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. + - ``sspush x1/x5`` instruction pushes (stores) `x1/x5`` to shadow stack. - - `sspopchk x1/x5` instruction pops (loads) from shadow stack and compares - with `x1/x5` and if un-equal, CPU raises `software check exception` with - `*tval =3D 3` + - ``sspopchk x1/x5`` instruction pops (loads) from shadow stack and compa= res + with ``x1/x5`` and if not equal, CPU raises software check exception + with ``*tval =3D 3`` -Compiler toolchain makes sure that function prologs have `sspush x1/x5` to= save return -address on shadow stack in addition to regular stack. Similarly function e= pilogs have -`ld x5, offset(x2)`; `sspopchk x5` to ensure that popped value from regula= r stack -matches with popped value from shadow stack. +Compiler toolchain makes sure that function prologs have ``sspush x1/x5`` = to +save return address on shadow stack in addition to regular stack. Similarly +function epilogs have ``ld x5, offset(x2); sspopchk x5`` to ensure that po= pped +value from regular stack matches with popped value from shadow stack. 2. Shadow stack protections and linux memory manager ----------------------------------------------------- As mentioned earlier, shadow stack get new page table encodings and thus h= ave some -special properties assigned to them and instructions that operate on them = as below +special properties assigned to them and instructions that operate on them = as below: - Regular stores to shadow stack memory raises access store faults. This way shadow stack memory is protected from stray inadvertant @@ -60,11 +60,11 @@ special properties assigned to them and instructions th= at operate on them as bel shadow 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` + AMO/store page fault. Thus both ``sspush x1/x5`` and ``sspopchk x1/x5`` will raise AMO/store page fault. This simplies COW handling in kernel During fork, kernel can convert shadow stack pages into read-only memory (as it does for regular read-write memory) and as soon as - subsequent `sspush` or `sspopchk` in userspace is encountered, then + subsequent ``sspush`` or ``sspopchk`` in userspace is encountered, then kernel can perform COW. - Shadow stack load / shadow stack store on read-write, read-write- @@ -75,8 +75,8 @@ special properties assigned to them and instructions that= operate on them as bel 3. ELF and psABI ----------------- -Toolchain sets up `GNU_PROPERTY_RISCV_FEATURE_1_BCFI` for property -`GNU_PROPERTY_RISCV_FEATURE_1_AND` in notes section of the object file. +Toolchain sets up ``GNU_PROPERTY_RISCV_FEATURE_1_BCFI`` for property +``GNU_PROPERTY_RISCV_FEATURE_1_AND`` in notes section of the object file. 4. Linux enabling ------------------ @@ -89,25 +89,25 @@ shadow stack for the program. 5. prctl() enabling -------------------- -`PR_SET_SHADOW_STACK_STATUS` / `PR_GET_SHADOW_STACK_STATUS` / -`PR_LOCK_SHADOW_STACK_STATUS` are three prctls added to manage shadow stack +``PR_SET_SHADOW_STACK_STATUS`` / ``PR_GET_SHADOW_STACK_STATUS`` / +``PR_LOCK_SHADOW_STACK_STATUS`` are three prctls added to manage shadow st= ack enabling for tasks. prctls are arch agnostic and returns -EINVAL on other = arches. -`PR_SET_SHADOW_STACK_STATUS`: If arg1 `PR_SHADOW_STACK_ENABLE` and if CPU = supports -`zicfiss` then kernel will enable shadow stack for the task. Dynamic loade= r can -issue this `prctl` once it has determined that all the objects loaded in a= ddress -space have support for shadow stack. Additionally if there is a `dlopen` t= o an -object which wasn't compiled with `zicfiss`, dynamic loader can issue this= prctl -with arg1 set to 0 (i.e. `PR_SHADOW_STACK_ENABLE` being clear) +``PR_SET_SHADOW_STACK_STATUS``: If arg1 ``PR_SHADOW_STACK_ENABLE`` and if = CPU supports +``zicfiss`` then kernel will enable shadow stack for the task. Dynamic loa= der can +issue this ``prctl`` once it has determined that all the objects loaded in= address +space have support for shadow stack. Additionally if there is a ``dlopen``= to an +object which wasn't compiled with ``zicfiss``, dynamic loader can issue th= is prctl +with arg1 set to 0 (i.e. ``PR_SHADOW_STACK_ENABLE`` being clear) -`PR_GET_SHADOW_STACK_STATUS`: Returns current status of indirect branch tr= acking. -If enabled it'll return `PR_SHADOW_STACK_ENABLE` +``PR_GET_SHADOW_STACK_STATUS``: Returns current status of indirect branch = tracking. +If enabled it'll return ``PR_SHADOW_STACK_ENABLE`` -`PR_LOCK_SHADOW_STACK_STATUS`: Locks current status of shadow stack enabli= ng on the -task. User space may 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 -disabling of shadow stack on current task. In that case user space can use= this prctl -to lock current settings. +``PR_LOCK_SHADOW_STACK_STATUS``: Locks current status of shadow stack enab= ling +on the task. User space may 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 disabling 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 ----------------------------------------------------------- @@ -115,22 +115,22 @@ to lock current settings. Pertaining to shadow stack, CPU raises software check exception in followi= ng condition - - On execution of `sspopchk x1/x5`, x1/x5 didn't match top of shadow stac= k. - If mismatch happens then cpu does `*tval =3D 3` and raise software check - exception + - On execution of ``sspopchk x1/x5``, x1/x5 didn't match top of shadow + stack. If mismatch happens then cpu does ``*tval =3D 3`` and rai= se + software check exception. -Linux kernel will treat this as `SIGSEV`` with code =3D `SEGV_CPERR` and f= ollow +Linux kernel will treat this as ``SIGSEV`` with ``SEGV_CPERR`` code and fo= llow 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 shad= ow stack -is simply writing to csr `CSR_SSP` changes active shadow stack. This can b= e 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. Shadow stack tokens can help mitigate this = problem by -making sure that: +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 st= ack. +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 rang= e. +Shadow stack tokens can help mitigate this problem by making sure that: - When software is switching away from a shadow stack, shadow stack point= er should be saved on shadow stack itself and call it `shadow stack token` @@ -139,31 +139,34 @@ making sure that: from shadow stack pointer and verify that `shadow stack token` itself i= s pointer to shadow stack itself. - - Once the token verification is done, software can perform the write to = `CSR_SSP` to - switch shadow stack. + - 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 vario= us contexts -as part of single thread. Software can be kernel as well when kernel has t= o 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= 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 `sigreturn`. Adversary = will have to -make sure that there is a `shadow stack token` in addition to invoking `si= greturn` +Here software can be user mode task runtime itself which is managing vario= us +contexts as part of single thread. Software can be kernel as well when ker= nel +has to deliver a signal to user task and must save shadow stack pointer. K= ernel +can perform similar procedure by saving a token on user shadow stack itsel= f. +This way whenever 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 adversa= ry by +arbitrarily using ``sigreturn``. Adversary will have to make sure that the= re is +a `shadow stack token` in addition to invoking ``sigreturn`` 7. Signal shadow stack ----------------------- -Following structure has been added to sigcontext for RISC-V. `rsvd` field = has been kept -in case we need some extra information in future for landing pads / indire= ct branch -tracking. It has been kept today in order to allow backward compatibility = in future:: +Following structure has been added to sigcontext for RISC-V. ``rsvd`` fiel= d has +been kept in case we need some extra information in future for landing pad= s / +indirect branch tracking. It has been kept today in order to allow backward +compatibility in future:: struct __sc_riscv_cfi_state { unsigned long ss_ptr; unsigned long rsvd; }; -As part of signal delivery, shadow stack token is saved on current shadow = stack itself and -updated pointer is saved away in `ss_ptr` field in `__sc_riscv_cfi_state` = under `sigcontext` -Existing shadow stack allocation is used for signal delivery. During `sigr= eturn`, kernel will -obtain `ss_ptr` from `sigcontext` and verify the saved token on shadow sta= ck itself and switch -shadow stack. +As part of signal delivery, shadow stack token is saved on current shadow = stack +itself and updated pointer is saved away in ``ss_ptr`` field in +``__sc_riscv_cfi_state`` under ``sigcontext`` Existing shadow stack alloca= tion +is used for signal delivery. During ``sigreturn``, kernel will obtain +``ss_ptr`` from ``sigcontext`` and verify the saved token on shadow stack +itself and switch shadow stack. Thanks. --=20 An old man doll... just what I always wanted! - Clara --cfhcWBhyYL8bTXY7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSSYQ6Cy7oyFNCHrUH2uYlJVVFOowUCZuekCAAKCRD2uYlJVVFO o++5AP9Xu2vqD0dx3z2ctEtTVxfDn/hZ0MG1BdgPDbMcuONwlQD/a5DYWvzVdYIn M3JiT/WxCGHof1VpWC4uaWz4jKV08gE= =Xiks -----END PGP SIGNATURE----- --cfhcWBhyYL8bTXY7--