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 BA618C28B2F for ; Fri, 14 Mar 2025 08:34:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 967AF280011; Fri, 14 Mar 2025 04:34:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8F263280001; Fri, 14 Mar 2025 04:34:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 76D13280011; Fri, 14 Mar 2025 04:34:49 -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 56807280001 for ; Fri, 14 Mar 2025 04:34:49 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id AD80080C52 for ; Fri, 14 Mar 2025 08:34:49 +0000 (UTC) X-FDA: 83219495898.04.C495F2E Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) by imf22.hostedemail.com (Postfix) with ESMTP id CC389C0004 for ; Fri, 14 Mar 2025 08:34:47 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=sifive.com header.s=google header.b=lgcAkaS4; spf=pass (imf22.hostedemail.com: domain of zong.li@sifive.com designates 209.85.166.41 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=1741941287; 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=bm74IWNiiddtjCmKDIAkneaMK7FpbJuBZ2ZaX1ZQ1kw=; b=f+y7nqh8PsdJz0uJRcqoGjT8n4ffjJ04WYoHOv4NvV8vJR7KH7OJFpXX6IAnH12oxeY9q7 MZ05geJUxWFi84qwUrnoBQxRwCIMAMCXv01o5hIk2PGSMR+wPk54j46Ck3gURbAU9UWXMy 3PNpjQrYUEQbjGDTmtDEYnfnrjoq6Gs= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=sifive.com header.s=google header.b=lgcAkaS4; spf=pass (imf22.hostedemail.com: domain of zong.li@sifive.com designates 209.85.166.41 as permitted sender) smtp.mailfrom=zong.li@sifive.com; dmarc=pass (policy=reject) header.from=sifive.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741941287; a=rsa-sha256; cv=none; b=gMZc2MviWAzpVfK2N52tVB6KWVmZG+rEaKJyqjGXYbdqxLM3IdStauYVWVZ2T5bXBbNjTr gVAoHvKwe4jiRVo6pSWjpymYaGg/Ybus3UGLNJMAsgKmlG0x+xDpm5lwCxSfGJUCIkCKPi AmTrY/BQlr5jWhycGG437CxY8+cfVsI= Received: by mail-io1-f41.google.com with SMTP id ca18e2360f4ac-85ae131983eso162972539f.0 for ; Fri, 14 Mar 2025 01:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1741941287; x=1742546087; 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=bm74IWNiiddtjCmKDIAkneaMK7FpbJuBZ2ZaX1ZQ1kw=; b=lgcAkaS42NhY7PRwDMiqx62KMqeRvnZaOPxJOrSdpSmp2NdOY8prnKK6roYLUSTWq0 4x+pw+z/3J3lbguSxC8q9D68N+iSXpSsnYDPyjgJ9bU7Fa6KztnOYm4IlzrxqaPK+Xlm hQp2C7R3snTzlYw0aAShbUFV8FxusUeHiVVk7FX07DZinlytEBvLKEyyyjwo8RID1Tq4 aaVHyqHiSNz5rIj/o0yu5FJthE+YL2ffDEfMawOYmfyq7/VCdiYL4C11fQDIV193o+G5 sB/11QHCuVSIiDWBHP0o9EOx+P43/pmGnkhX522y/MIAHVR8FnVkKE7e1tds6ULT3xiN IVsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741941287; x=1742546087; 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=bm74IWNiiddtjCmKDIAkneaMK7FpbJuBZ2ZaX1ZQ1kw=; b=Wh5+pWcg6gkTHpaFbXfhe9iYr48dmAXhl/p9dnTR87Ac+87yhV5TCts78ScyLan/ac t2WBnxiL3Gdq7sToIPy1yq8PlZok0BINI6HxmqgEub9pWI6O5OySnbETvidcoHmBH5YU SsunIQixAQrOg5VW1lyWabdE00UnHTwUcjstDbxCdIfp4knYTtGhcUhi8p8YJLhljLAK vjVi9gHTDxZbAHYGbVWeaWt2cv9Uk+Gc8uLes+EbP8K82sGBLroRupYMMuT/GFFAHyul p56NDVvIW0l7whOfeQrEvENO1Opegsq0iq5Bb4nG2Uh/2lvB3wOzJWrKrfpz8QNPDoYp iKPw== X-Forwarded-Encrypted: i=1; AJvYcCULSlrMlYX2VeBcIgM5OOoZ4PoYLo/YmhIXWzBXUO1wOi8+f+eFJDN/tUxI+BxQ9ORSBabIa7MwQw==@kvack.org X-Gm-Message-State: AOJu0YwPzpmDyXOzWoSv6QA45S95ttvpAbztsCLVz7EgtRoIZAQbVyev I85v4tvTcxyY2LE0VmqIl0JtgFgNztNVp9qnaKLhkQYkPOJwKDXDNqeDvMpatn9YQuUZNqo9SyV lw8qR/KDjTd1FRd21lXr/Ok9PtE9MUguMpBkLrQ== X-Gm-Gg: ASbGncts4crLZYNt2ZDVt19jKXhSQYkh50jbvtxZIhhAipwHHY4grT7KfwAyQ2ABb1r IVdj6tHiMQfSHePJNKF3UKh6d2J+dQE7ApZ1zWeVJB7mYvSgBuPQxON65K5JvdeTTXqMHG0vcSe Or5TanciYKjqL7MPl4aClgmDwSN4g= X-Google-Smtp-Source: AGHT+IFRA5Az3Um9tJHHRXJFx+3mnIqGojBtFl6JREsVb2G4EXt33cQMlFoJn1d6ltMZlRWKhpPmG6wKGqrSmlkGBr0= X-Received: by 2002:a05:6602:3f08:b0:85b:5869:b5b with SMTP id ca18e2360f4ac-85dc48334c9mr187830339f.6.1741941286887; Fri, 14 Mar 2025 01:34:46 -0700 (PDT) MIME-Version: 1.0 References: <20250310-v5_user_cfi_series-v11-0-86b36cbfb910@rivosinc.com> <20250310-v5_user_cfi_series-v11-25-86b36cbfb910@rivosinc.com> In-Reply-To: <20250310-v5_user_cfi_series-v11-25-86b36cbfb910@rivosinc.com> From: Zong Li Date: Fri, 14 Mar 2025 16:34:36 +0800 X-Gm-Features: AQ5f1JpXeE6tU44day2kKwZlk-ke3YkF8t6JJiPonVbxjr2JHrkve7GNBaApiH4 Message-ID: Subject: Re: [PATCH v11 25/27] riscv: Documentation for landing pad / indirect branch tracking 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-Queue-Id: CC389C0004 X-Rspamd-Server: rspam03 X-Stat-Signature: 3fh7ieg6qfo3bhh4o16m75t1ey3esw5k X-HE-Tag: 1741941287-678047 X-HE-Meta: U2FsdGVkX1/AJefB99ZqqzuEqcxMOuTf4UVKKvJa0zgfXfNUp0PxFDD0esWD/dOtZ9DGedI3l6AW50Uy5LSBernagAWpAfWNPfsyrJI2aPwPkpG3yhudfs6tGhmIfGXTpFEE+QXMVrKXxREQYBQ+7FM6Wjm7h2z2N7EAggPUOfdboOptcWrnWJGJMuAfC/uuwCXOv5+gB2NerciJfl/nUolUlsafvsO2zfvLYhpfaciKrtwY1IHuIFLZ+jM9DiWOJ0AfcUTzMBfETf9mEVLDOadaG4bh8cikxdEVGHxvKIbDU4ejE2Koowv4VTbi/rbrk72XIpIxoxnFjuLWJXZL8s+cwLFRLGtf5D6fFO3H0MBXQu7I5RWmuU3MQPRG6l5rZesDXCUWBv+WbrHNFbry61TgpM8GJCVON9EnEy6aL4qqMIUNsb8keB9KQVlngtUlhHGioHgbQFZdTTN9HsqnJagNxKrbkNyjMBlaLcZk7PROaTnc3HoRS3J8o7ZEOFsteARAMbXO6NXUQ6DlWHiCTNiJOdpgFPHwmR+WSworqrLqFy7tAQw1LrjOd3PtUI+YThJw0OnAewYM9yldPfDOG1i9cl5A+DpjrTLPfpP79PhjCX0fj1i7ihtL64Y0OvJeUpG4IszaBX7KAQAFQFPCyE8G3P/GIYDBZ3IQ6gUKrkybpMch2z0AASEmOxF7jgJh0X+I3ZJ6obKx+3b8qAm2Y5Blj7oAc/vIwM/9xU2l8bWtvqs56zqv2BpW0/onrb39FaIDhmOjH6kzgZ7ybKN5CUbnjFLGwStWXicenrSKvD2JiIddTB+KLXtnY00Ng/C0JQCqnyPefdzFIt1LigHFLRQCdK/BtCM2NKYP/brqL4aumudPRLnVYDJmM1T6rREb8tgR9nsMOB3zscGBf84YVrh6OsxyQSSfAosUs7Ax0zwKbknsJ/8T1baYJl2YCgmtZf4P4x+Liv9nHaje4/3 5XOX1PoE W3VOJd5smUCn/YcbsUiI5dsW0o+c3kuMosKGspbFeennqule1lmfcodjrzIdCUlbXTu1aKf0fcj2V/GwJwvkoOpNDLv/v8q0VgO2xN/aIkhrTPwJa4oa4uyJ5UrYqpKZCtfY+3IwOjmGchzKwBxYNsTjT3tChh9GsWKN9cFJF2YUgn6uuBwMuLAp4QbWli1wWdkL41lG+tsX7l8BQDw3jDzS/RjbHkCeXriP7DB2gT/NMjd5FeDTN+hJpF1a3uGllfWypCg6141mJsUZ8WmKrA0tBxtlDzNiXr0JLzqsqRk4Q7YmM6U2e9X8h6GU6XjVk6j55ck4/xQ6Gj8EFXzcwrh+ee2IGb4Yn76pr5q2sWK6rNrGYbFc3XRLRUTqxCHAymCkSkIw8YQi2BI0mE4ABSq6qtLOYNmPvk2Ts2+v9boAoM7Vu1YjEqpRBWb7yZJmdxEa7 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 landing pad aka indirect branch tracking 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/zicfilp.rst | 115 +++++++++++++++++++++++++++++= ++++++ > 2 files changed, 116 insertions(+) > > diff --git a/Documentation/arch/riscv/index.rst b/Documentation/arch/risc= v/index.rst > index eecf347ce849..be7237b69682 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 > > diff --git a/Documentation/arch/riscv/zicfilp.rst b/Documentation/arch/ri= scv/zicfilp.rst > new file mode 100644 > index 000000000000..a188d78fcde6 > --- /dev/null > +++ b/Documentation/arch/riscv/zicfilp.rst > @@ -0,0 +1,115 @@ > +.. 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 > +Tracking indirect control transfers 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 > + > +This document briefly describes the interface provided to userspace by L= inux > +to enable indirect branch tracking 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 function pointers and chain them together to perform jum= p oriented > +programming (JOP) or call oriented programming (COP) and thus compromisi= ng control > +flow integrity (CFI) of the program. > + > +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 do= n't rely > + on memory and thus rs1=3Dx7 is exempted from tracking and considered= software > + guarded jumps. > + > +``lpad`` instruction is pseudo of ``auipc rd, `` with ``rd=3D= x0`` and > +is a HINT nop. ``lpad`` instruction must be aligned on 4 byte boundary a= nd > +compares 20 bit immediate withx7. If ``imm_20bit`` =3D=3D 0, CPU don't p= erform any > +comparision with ``x7``. If ``imm_20bit`` !=3D 0, then ``imm_20bit`` mus= t match > +``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 (tr= uncated > +to 20bit) in x7 at callsites and function prologues can have ``lpad`` wi= th same > +function hash. This further reduces number of program counters a call si= te can > +reach. > + > +2. ELF and psABI > +----------------- > + > +Toolchain sets up :c:macro:`GNU_PROPERTY_RISCV_FEATURE_1_FCFI` for prope= rty > +:c:macro:`GNU_PROPERTY_RISCV_FEATURE_1_AND` in notes section of the obje= ct file. > + > +3. 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 indirect branch. Thus it's left to dynamic loader to ena= ble > +indirect branch tracking for the program. > + > +4. prctl() enabling > +-------------------- > + > +:c:macro:`PR_SET_INDIR_BR_LP_STATUS` / :c:macro:`PR_GET_INDIR_BR_LP_STAT= US` / > +:c:macro:`PR_LOCK_INDIR_BR_LP_STATUS` are three prctls added to manage i= ndirect > +branch tracking. prctls are arch agnostic and returns -EINVAL on other a= rches. > + > +* prctl(PR_SET_INDIR_BR_LP_STATUS, unsigned long arg) > + > +If arg1 is :c:macro:`PR_INDIR_BR_LP_ENABLE` and if CPU supports ``zicfil= p`` > +then kernel will enabled indirect branch tracking for the task. Dynamic = loader > +can issue this :c:macro:`prctl` once it has determined that all the obje= cts > +loaded in address space support indirect branch tracking. Additionally i= f there > +is a `dlopen` to an object which wasn't compiled with ``zicfilp``, dynam= ic > +loader can issue this prctl with arg1 set to 0 (i.e. > +:c:macro:`PR_INDIR_BR_LP_ENABLE` being clear) > + > +* prctl(PR_GET_INDIR_BR_LP_STATUS, unsigned long arg) > + > +Returns current status of indirect branch tracking. If enabled it'll ret= urn > +:c:macro:`PR_INDIR_BR_LP_ENABLE` > + > +* prctl(PR_LOCK_INDIR_BR_LP_STATUS, unsigned long arg) > + > +Locks current status of indirect branch tracking on the task. User space= may > +want to run with strict security posture and wouldn't want loading of ob= jects > +without ``zicfilp`` support in it and thus would want to disallow disabl= ing of > +indirect branch tracking. In that case user space can use this prctl to = lock > +current settings. > + > +5. violations related to indirect branch tracking > +-------------------------------------------------- > + > +Pertaining to indirect branch tracking, CPU raises software check except= ion 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= `` > + > +In all 3 cases, ``*tval =3D 2`` is captured and software check exception= is > +raised (``cause=3D18``) > + > +Linux kernel will treat this as :c:macro:`SIGSEV`` with code =3D > +:c:macro:`SEGV_CPERR` and follow normal course of signal delivery. > 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