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 1A369C3ABC7 for ; Mon, 16 Sep 2024 02:41:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A3E16B0089; Sun, 15 Sep 2024 22:41:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 153996B008A; Sun, 15 Sep 2024 22:41:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EE7E96B008C; Sun, 15 Sep 2024 22:41:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id C773B6B0089 for ; Sun, 15 Sep 2024 22:41:19 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5A9761401CF for ; Mon, 16 Sep 2024 02:41:19 +0000 (UTC) X-FDA: 82569049878.02.D4CBFDC Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com [209.85.210.196]) by imf19.hostedemail.com (Postfix) with ESMTP id 566C31A0007 for ; Mon, 16 Sep 2024 02:41:17 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fDzBXCnE; spf=pass (imf19.hostedemail.com: domain of bagasdotme@gmail.com designates 209.85.210.196 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=1726454368; 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=mQ7bc5SqcE0TyYrB+t+d7+/GZbyQXftQ6Hsj5bON1WY=; b=rls7RlC42LMfDfIsehuxt+0ckLBa6nzzAZaPeKbevCzwUtME8fqpajhZSAR0zBTMecPxh0 nh/MiV5pQkc1vuBSTeNh9IHJRicfZ5iPsOFpUxPAOsIitSeJWFCX1zqCMkhqWneVo6ztq1 h8LkjPcfIxlPHrh4tCmcuByDdfko57Y= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726454368; a=rsa-sha256; cv=none; b=xMzCspigi0lIWJVWyZb3n2jps4TpioebFReOQd4kBO3iFso48XphBpHOVmKqLBfXGtXJF4 eDWgE42uW2ozo1BS69OTgh4stMMSQ1ayFLW/6a9pJWeCZf2g9BHJCMiOP3gafjI3knSKiR neIwN+v6Y7NoaJeQQdQXLG6/+j45eew= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fDzBXCnE; spf=pass (imf19.hostedemail.com: domain of bagasdotme@gmail.com designates 209.85.210.196 as permitted sender) smtp.mailfrom=bagasdotme@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pf1-f196.google.com with SMTP id d2e1a72fcca58-718da0821cbso2995195b3a.0 for ; Sun, 15 Sep 2024 19:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726454476; x=1727059276; 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=mQ7bc5SqcE0TyYrB+t+d7+/GZbyQXftQ6Hsj5bON1WY=; b=fDzBXCnEYGDoatRxNcsrsEfzlxdN/LbzCCzMqHpmqrNqjs35Yl3skfekyOuxoC81Ee BF5/1J4/G6KLsTZMtew44tTPJDvlbH8rOMqo8w7MpicCbNmrOme5wf2J49h7rjSuZVIu rnIcPb1ZfSfk3HkEHBIhtyv6JYi5dZFsLQZM6cujr6lt0Rn80SKXhyp6os1RC9D3+Gx9 IW1zHq4kzAeyyJXc3/p/KN95LlFv9q7sNKInba8jS0iHtkY4qdJuFKhPP3ZJwaepvj8j OPkz5rhA/LnNOgUrEk/d4G3RBTmBcHoohWVC3wkHUrG0vW0geBxfoGDI+X68jemjkBea W9oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726454476; x=1727059276; 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=mQ7bc5SqcE0TyYrB+t+d7+/GZbyQXftQ6Hsj5bON1WY=; b=CrVAMKJnfG1DwcRGpKUfBK6vUt2ofUm5nY8n811Qv/+l5PTWC1fzfZ6FQUawECu7cV /G2j+w0I4Gt7LT5NrVy9zmzY4VnGQWJ/4we1SOuAOW2yntloPFcLhQy1Bt+kkx2MbTmE NxRTZj5dLS9fzWxmB9OgU8WDk+qcN201DNstJUzGYBYRFbUdwIlDPqCpfzZ1MN1p1ToW J7dbftT5Dwkbt5q7fWGTmRHD9MMyUgkYmQlj4G+s6m1yCN05xkxEyrrm2/eBKriyy4b0 FFa1UsIogNrTUgnp33cm1l1o4c+znaVQa5BV/Mi2DjRLIGJ1Dqf4/sfCa9ksdltv1pa3 RsnA== X-Forwarded-Encrypted: i=1; AJvYcCUI5AwykELt7/akcBWvAgKvdTBOx+k5mRVm4b9vIN5cGNMbRTpUz4ltd/ijqsCDBG8/hJuPDu+kUA==@kvack.org X-Gm-Message-State: AOJu0YwzwvmdiO4OJyk3EQRjZSAiTlArT+d6DjsnNK81oaKaArrTzOIX gw6h8wksXLEOsLJkMr7dBbMR0qHD5Ng+t9lGTVBhPm3KU6J1Js87 X-Google-Smtp-Source: AGHT+IFlk7vmvpL5BheL0pnnHEN8PLDD1dYdjxgsveHq8yhqGq93AzDWA66AEBEZ9+h2dzbefdCaiQ== X-Received: by 2002:a05:6a00:2352:b0:714:3831:ec91 with SMTP id d2e1a72fcca58-71926213e47mr20154346b3a.25.1726454475421; Sun, 15 Sep 2024 19:41:15 -0700 (PDT) Received: from archie.me ([103.124.138.155]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-71944b9ac05sm2848411b3a.155.2024.09.15.19.41.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Sep 2024 19:41:15 -0700 (PDT) Received: by archie.me (Postfix, from userid 1000) id D32814A358AE; Mon, 16 Sep 2024 09:41:09 +0700 (WIB) Date: Mon, 16 Sep 2024 09:41:09 +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 28/30] riscv: Documentation for landing pad / indirect branch tracking Message-ID: References: <20240912231650.3740732-1-debug@rivosinc.com> <20240912231650.3740732-29-debug@rivosinc.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IJXqtcSEhuPy+P+r" Content-Disposition: inline In-Reply-To: <20240912231650.3740732-29-debug@rivosinc.com> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 566C31A0007 X-Stat-Signature: kwa886b9iw5uh1fqcs8pmgwhr831qj9b X-HE-Tag: 1726454477-970576 X-HE-Meta: U2FsdGVkX19Qwz0ANmjCH+KLWFS1qMAYfyJAmXx2b8IyDhMV2xfZ9ZNmWDf2luhXxphabPPPiNc9tbbBnLScd+/ih9dNNrnGDy0dnbVPr6nmIdGRPMCcwcBq/9agJh2JMPRErTe9gEDVmRIhAvNj7xZqpc4J6dMuquWk3VdNqzGDPbvFY62qmVWI4ZcrCo0zHzmZugZK08q5Wj2KEklro8P/e3qPc8t2F3H4rLo1/mPTdAVdNl4sC9Ja/A1M6nh7vADLYNiqLQnGhBWP+Adb4jeUm/2N2GbCOILsuwxa8sAn0Ug5EkxusBZ+iAiNCkB55jlAmcc1yxYfOlEsq2+03mCvIIE7PD+c0E7JPaF3A/4FTuPDZibGyqzVEXXv6eNxj9tR7NDTJ9UWgpUEbij0pB8V8WfFBB+5pZkJtvBgtUep19qecazewOgt3NkUu4yY35HKGNdgCCQ8nIZn79uqbLs17uhS++tTb6i5Ggm/vRm+YWz9+/GT4cyh0l7rAVRVrZgeyxL9U+OtsTdr/i/9FEIrWXX/gcwXSLi4rsWdGozjmzBvGT7bS6Yt7nahL/0gjhbYjyydDoQh7Z/l/IDhXGZEnXG3b06/Bgf1mbGuMe0bDMqUkctV35J45EfxK3On0yRcUN78t9tSj8yXT1YuQanBXId30EeArZlPN3qOgp5grawtMced2ItmKDcJgg+5zmvtyZzS0FSAYCErKK5stRF8dZ52UVh9sye8LAfOsaIfdiJwidfEmntuu62LsUcys93DiJ/C2MTlVd2RZsc2Duv9SD3Zusns2x5Tw5/22hYTsgG6iH3OqPDChjxpCMITg0xhZDlyxdYoKbi4koCdl5ajqmY5j0i0U3rUDHFCZ/oFgTo9dSe02dUmhJaImBWO0dhD2LCCiPbiZog8jYhYijpZQJz+9gvbO4ltW7M65vNcotvZdtbtxmbKzGQN+r4Cp3cbMg40BlAhrkFOxKs LI3he0vV V02QIVmezLC6jBO0KegF+W/rudgUS0hs9n0Q7ZAwu67zv3YNfnsOC7xFGZficuLizVIUnWre77ibEZsvuHPyJRSBi6UOzaDRSONtfq2zlDaQdGncmyaqUk1CzUDsei9JWv4G3Sfsa5vqHWmeOWz4QN5lfCpUgzpPSl/Q5KTOySwHGwSp30rQ3p8mfHu1Hv8DtcuMaWCygyktsofOyksw/zxX3BcvY6qoMwe/e7+05RK4wpTW+KYaArW4MoiUwIm9p+LhsCbxlN7aGF7bmNXh+IZ7uy9jhs76pJKTfhGjq4zvki6tGMwWR/mCL0t0z3m2IqWT2geZCJ7f5b7zLFLGBtQStk8BnMlzME1/5gMwUkV9WR5qNmchzp80tyjaambQxh/W33v8JJtzB3mNrbE1bNe7k9HvJpxIDSivQu7gonvPVuCw6czo7p6jMaZmamcyQRERC8WKgHJaAsbGtw/9Laq6s2WpJfDh7GkubqFw8NtoSO8Ot/JCx84InBe7ByZkeSsrRnM7nFtrKZMB0c6AlDMOCAZ/6OF1+xUOCmEkzw2XeMSiHNmzOC98oAIiBe55iN6p0dRimjH+zu+Ch+8TvCtawpQ2KayRbt/i83UFpEJ09zf8= 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: --IJXqtcSEhuPy+P+r Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 12, 2024 at 04:16:47PM -0700, Deepak Gupta wrote: > Adding documentation on landing pad aka indirect branch tracking on riscv > and kernel interfaces exposed so that user tasks can enable it. >=20 > Signed-off-by: Deepak Gupta > --- > Documentation/arch/riscv/zicfilp.rst | 104 +++++++++++++++++++++++++++ > 1 file changed, 104 insertions(+) > create mode 100644 Documentation/arch/riscv/zicfilp.rst Don't forget to add toctree entry: ---- >8 ---- diff --git a/Documentation/arch/riscv/index.rst b/Documentation/arch/riscv/= index.rst index eecf347ce84944..be7237b6968213 100644 --- a/Documentation/arch/riscv/index.rst +++ b/Documentation/arch/riscv/index.rst @@ -14,6 +14,7 @@ RISC-V architecture uabi vector cmodx + zicfilp features > +Function pointers live in read-write memory and thus are susceptible to = corruption > +and allows an adversary to reach any program counter (PC) in address spa= ce. On > +RISC-V zicfilp extension enforces a restriction on such indirect control= transfers > + > + - indirect control transfers must land on a landing pad instruction `lp= ad`. > + There are two exception to this rule > + - rs1 =3D x1 or rs1 =3D x5, i.e. a return from a function and returns = are > + protected using shadow stack (see zicfiss.rst) > + > + - rs1 =3D x7. On RISC-V compiler usually does below to reach function > + which is beyond the offset possible J-type instruction. > + > + "auipc x7, " > + "jalr (x7)" > + > + Such form of indirect control transfer are still immutable and don't= rely > + on memory and thus rs1=3Dx7 is exempted from tracking and considered= software > + guarded jumps. Sphinx reports new htmldocs warnings: Documentation/arch/riscv/zicfilp.rst:30: ERROR: Unexpected indentation. Documentation/arch/riscv/zicfilp.rst:96: ERROR: Unexpected indentation.=09 I have to fix up the lists: ---- >8 ---- diff --git a/Documentation/arch/riscv/zicfilp.rst b/Documentation/arch/risc= v/zicfilp.rst index 23013ee711ac2c..c0fad1b5caa3d8 100644 --- a/Documentation/arch/riscv/zicfilp.rst +++ b/Documentation/arch/riscv/zicfilp.rst @@ -23,22 +23,24 @@ flow integrity (CFI) of the program. Function pointers live in read-write memory and thus are susceptible to co= rruption and allows an adversary to reach any program counter (PC) in address space= =2E On -RISC-V zicfilp extension enforces a restriction on such indirect control t= ransfers +RISC-V zicfilp extension enforces a restriction on such indirect control +transfers: - - indirect control transfers must land on a landing pad instruction `lpad= `. - There are two exception to this rule - - rs1 =3D x1 or rs1 =3D x5, i.e. a return from a function and returns are - protected using shadow stack (see zicfiss.rst) +- indirect control transfers must land on a landing pad instruction `lpad`. + There are two exception to this rule: - - rs1 =3D x7. On RISC-V compiler usually does below to reach function - which is beyond the offset possible J-type instruction. + - rs1 =3D x1 or rs1 =3D x5, i.e. a return from a function and returns are + protected using shadow stack (see zicfiss.rst) - "auipc x7, " - "jalr (x7)" + - rs1 =3D x7. On RISC-V compiler usually does below to reach function + which is beyond the offset possible J-type instruction. - Such form of indirect control transfer are still immutable and don't r= ely - on memory and thus rs1=3Dx7 is exempted from tracking and considered s= oftware - guarded jumps. + "auipc x7, " + "jalr (x7)" + + Such form of indirect control transfer are still immutable and don't r= ely + on memory and thus rs1=3Dx7 is exempted from tracking and considered s= oftware + guarded jumps. `lpad` instruction is pseudo of `auipc rd, ` with `rd=3Dx0`` an= d is a HINT nop. `lpad` instruction must be aligned on 4 byte boundary and compares 20= bit @@ -92,10 +94,11 @@ to lock current settings. -------------------------------------------------- Pertaining to indirect branch tracking, CPU raises software check exceptio= n in -following conditions - - missing `lpad` after indirect call / jmp - - `lpad` not on 4 byte boundary - - `imm_20bit` embedded in `lpad` instruction doesn't match with `x7` +following conditions: + +- missing `lpad` after indirect call / jmp +- `lpad` not on 4 byte boundary +- `imm_20bit` embedded in `lpad` instruction doesn't match with `x7` In all 3 cases, `*tval =3D 2` is captured and software check exception is = raised (cause=3D18) > + > +`lpad` instruction is pseudo of `auipc rd, ` with `rd=3Dx0`` = and is a HINT > +nop. `lpad` instruction must be aligned on 4 byte boundary and compares = 20 bit > +immediate withx7. If `imm_20bit` =3D=3D 0, CPU don't perform any compari= sion with x7. If > +`imm_20bit` !=3D 0, then `imm_20bit` must match x7 else CPU will raise > +`software check exception` (cause=3D18)with `*tval =3D 2`. > + Also inline identifiers/keywords to be consistent with rest of riscv docs: ---- >8 ---- diff --git a/Documentation/arch/riscv/zicfilp.rst b/Documentation/arch/risc= v/zicfilp.rst index c0fad1b5caa3d8..b0a766098f2335 100644 --- a/Documentation/arch/riscv/zicfilp.rst +++ b/Documentation/arch/riscv/zicfilp.rst @@ -26,38 +26,38 @@ and allows an adversary to reach any program counter (P= C) in address space. On RISC-V zicfilp extension enforces a restriction on such indirect control transfers: -- indirect control transfers must land on a landing pad instruction `lpad`. +- indirect control transfers must land on a landing pad instruction ``lpad= ``. There are two exception to this rule: - rs1 =3D x1 or rs1 =3D x5, i.e. a return from a function and returns are protected using shadow stack (see zicfiss.rst) - rs1 =3D x7. On RISC-V compiler usually does below to reach function - which is beyond the offset possible J-type instruction. + which is beyond the offset possible J-type instruction:: - "auipc x7, " - "jalr (x7)" + auipc x7, + jalr (x7) Such form of indirect control transfer are still immutable and don't r= ely on memory and thus rs1=3Dx7 is exempted from tracking and considered s= oftware guarded jumps. -`lpad` instruction is pseudo of `auipc rd, ` with `rd=3Dx0`` an= d is a HINT -nop. `lpad` instruction must be aligned on 4 byte boundary and compares 20= bit -immediate withx7. If `imm_20bit` =3D=3D 0, CPU don't perform any comparisi= on with x7. If -`imm_20bit` !=3D 0, then `imm_20bit` must match x7 else CPU will raise -`software check exception` (cause=3D18)with `*tval =3D 2`. +``lpad`` instruction is pseudo of ``auipc rd, `` with ``rd=3Dx0= `` and +is a HINT nop. ``lpad`` instruction must be aligned on 4 byte boundary and +compares 20 bit immediate with x7. If ``imm_20bit`` =3D=3D 0, CPU don't pe= rform any +comparision with x7. If ``imm_20bit`` !=3D 0, then ``imm_20bit`` must matc= h x7 +else CPU will raise software check exception (cause=3D18) with ``*tval =3D= 2``. Compiler can generate a hash over function signatures and setup them (trun= cated -to 20bit) in x7 at callsites and function prologues can have `lpad` with s= ame +to 20bit) in x7 at callsites and function prologues can have ``lpad`` with= same function hash. This further reduces number of program counters a call site= can reach. 2. ELF and psABI ----------------- -Toolchain sets up `GNU_PROPERTY_RISCV_FEATURE_1_FCFI` for property -`GNU_PROPERTY_RISCV_FEATURE_1_AND` in notes section of the object file. +Toolchain sets up ``GNU_PROPERTY_RISCV_FEATURE_1_FCFI`` for property +``GNU_PROPERTY_RISCV_FEATURE_1_AND`` in notes section of the object file. 3. Linux enabling ------------------ @@ -70,25 +70,26 @@ indirect branch tracking for the program. 4. prctl() enabling -------------------- -`PR_SET_INDIR_BR_LP_STATUS` / `PR_GET_INDIR_BR_LP_STATUS` / -`PR_LOCK_INDIR_BR_LP_STATUS` are three prctls added to manage indirect bra= nch +``PR_SET_INDIR_BR_LP_STATUS`` / ``PR_GET_INDIR_BR_LP_STATUS`` / +``PR_LOCK_INDIR_BR_LP_STATUS`` are three prctls added to manage indirect b= ranch tracking. prctls are arch agnostic and returns -EINVAL on other arches. -`PR_SET_INDIR_BR_LP_STATUS`: If arg1 `PR_INDIR_BR_LP_ENABLE` and if CPU su= pports -`zicfilp` then kernel will enabled indirect branch tracking for the task. -Dynamic loader can issue this `prctl` once it has determined that all the = objects -loaded in address space support indirect branch tracking. Additionally if = there is -a `dlopen` to an object which wasn't compiled with `zicfilp`, dynamic load= er can -issue this prctl with arg1 set to 0 (i.e. `PR_INDIR_BR_LP_ENABLE` being cl= ear) +``PR_SET_INDIR_BR_LP_STATUS``: If arg1 ``PR_INDIR_BR_LP_ENABLE`` and if CPU +supports ``zicfilp`` then kernel will enabled indirect branch tracking for= the +task. Dynamic loader can issue this ``prctl`` once it has determined that = all +the objects loaded in address space support indirect branch tracking. +Additionally if there is a ``dlopen`` to an object which wasn't compiled w= ith +``zicfilp``, dynamic loader can issue this prctl with arg1 set to 0 (i.e. +``PR_INDIR_BR_LP_ENABLE`` being clear) -`PR_GET_INDIR_BR_LP_STATUS`: Returns current status of indirect branch tra= cking. -If enabled it'll return `PR_INDIR_BR_LP_ENABLE` +``PR_GET_INDIR_BR_LP_STATUS``: Returns current status of indirect branch +tracking. If enabled it'll return ``PR_INDIR_BR_LP_ENABLE`` -`PR_LOCK_INDIR_BR_LP_STATUS`: Locks current status of indirect branch trac= king on -the task. User space may want to run with strict security posture and woul= dn't want -loading of objects without `zicfilp` support in it and thus would want to = disallow -disabling of indirect branch tracking. In that case user space can use thi= s prctl -to lock current settings. +``PR_LOCK_INDIR_BR_LP_STATUS``: Locks current status of indirect branch +tracking on the task. User space may want to run with strict security post= ure +and wouldn't want loading of objects without ``zicfilp`` support in it and= thus +would want to disallow disabling of indirect branch tracking. In that case= user +space can use this prctl to lock current settings. 5. violations related to indirect branch tracking -------------------------------------------------- @@ -96,12 +97,12 @@ to lock current settings. Pertaining to indirect branch tracking, CPU raises software check exceptio= n in following conditions: -- missing `lpad` after indirect call / jmp -- `lpad` not on 4 byte boundary -- `imm_20bit` embedded in `lpad` instruction doesn't match with `x7` +- missing ``lpad`` after indirect call / jmp +- ``lpad`` not on 4 byte boundary +- ``imm_20bit`` embedded in ``lpad`` instruction doesn't match with x7 -In all 3 cases, `*tval =3D 2` is captured and software check exception is = raised +In all 3 cases, ``*tval =3D 2`` is captured and software check exception i= s raised (cause=3D18) -Linux kernel will treat this as `SIGSEV`` with code =3D `SEGV_CPERR` and f= ollow +Linux kernel will treat this as ``SIGSEV`` with code =3D ``SEGV_CPERR`` an= d follow normal course of signal delivery. Thanks. --=20 An old man doll... just what I always wanted! - Clara --IJXqtcSEhuPy+P+r Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSSYQ6Cy7oyFNCHrUH2uYlJVVFOowUCZueawQAKCRD2uYlJVVFO o72rAP0f2qcQlNSisvlhhZn9AoKwhyuBcmQUB3iNJOvDWNAp/gD7BxOWxP3cyxbX Y3SfLQ1Amz7nw/R2vuD/vMlR498G6Ak= =GJtS -----END PGP SIGNATURE----- --IJXqtcSEhuPy+P+r--