From: Deepak Gupta <debug@rivosinc.com> To: paul.walmsley@sifive.com, rick.p.edgecombe@intel.com, broonie@kernel.org, Szabolcs.Nagy@arm.com, kito.cheng@sifive.com, keescook@chromium.org, ajones@ventanamicro.com, conor.dooley@microchip.com, cleger@rivosinc.com, atishp@atishpatra.org, alex@ghiti.fr, bjorn@rivosinc.com, alexghiti@rivosinc.com, samuel.holland@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-mm@kvack.org, linux-arch@vger.kernel.org, linux-kselftest@vger.kernel.org Cc: corbet@lwn.net, tech-j-ext@lists.risc-v.org, palmer@dabbelt.com, aou@eecs.berkeley.edu, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, oleg@redhat.com, akpm@linux-foundation.org, arnd@arndb.de, ebiederm@xmission.com, Liam.Howlett@oracle.com, vbabka@suse.cz, lstoakes@gmail.com, shuah@kernel.org, brauner@kernel.org, debug@rivosinc.com, andy.chiu@sifive.com, jerry.shih@sifive.com, hankuan.chen@sifive.com, greentime.hu@sifive.com, evan@rivosinc.com, xiao.w.wang@intel.com, charlie@rivosinc.com, apatel@ventanamicro.com, mchitale@ventanamicro.com, dbarboza@ventanamicro.com, sameo@rivosinc.com, shikemeng@huaweicloud.com, willy@infradead.org, vincent.chen@sifive.com, guoren@kernel.org, samitolvanen@google.com, songshuaishuai@tinylab.org, gerg@kernel.org, heiko@sntech.de, bhe@redhat.com, jeeheng.sia@starfivetech.com, cyy@cyyself.name, maskray@google.com, ancientmodern4@gmail.com, mathis.salmen@matsal.de, cuiyunhui@bytedance.com, bgray@linux.ibm.com, mpe@ellerman.id.au, baruch@tkos.co.il, alx@kernel.org, david@redhat.com, catalin.marinas@arm.com, revest@chromium.org, josh@joshtriplett.org, shr@devkernel.io, deller@gmx.de, omosnace@redhat.com, ojeda@kernel.org, jhubbard@nvidia.com Subject: [PATCH v2 25/27] riscv: Documentation for landing pad / indirect branch tracking Date: Thu, 28 Mar 2024 21:44:57 -0700 [thread overview] Message-ID: <20240329044459.3990638-26-debug@rivosinc.com> (raw) In-Reply-To: <20240329044459.3990638-1-debug@rivosinc.com> 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 <debug@rivosinc.com> --- Documentation/arch/riscv/zicfilp.rst | 104 +++++++++++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 Documentation/arch/riscv/zicfilp.rst diff --git a/Documentation/arch/riscv/zicfilp.rst b/Documentation/arch/riscv/zicfilp.rst new file mode 100644 index 000000000000..3007c81f0465 --- /dev/null +++ b/Documentation/arch/riscv/zicfilp.rst @@ -0,0 +1,104 @@ +.. SPDX-License-Identifier: GPL-2.0 + +:Author: Deepak Gupta <debug@rivosinc.com> +:Date: 12 January 2024 + +==================================================== +Tracking indirect control transfers on RISC-V Linux +==================================================== + +This document briefly describes the interface provided to userspace by Linux +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 hands of +an adversary and if used creatively can result into variety security issues. + +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 jump oriented +programming (JOP) or call oriented programming (COP) and thus compromising 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 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`. + There are two exception to this rule + - rs1 = x1 or rs1 = x5, i.e. a return from a function and returns are + protected using shadow stack (see zicfiss.rst) + + - rs1 = x7. On RISC-V compiler usually does below to reach function + which is beyond the offset possible J-type instruction. + + "auipc x7, <imm>" + "jalr (x7)" + + Such form of indirect control transfer are still immutable and don't rely + on memory and thus rs1=x7 is exempted from tracking and considered software + guarded jumps. + +`lpad` instruction is pseudo of `auipc rd, <imm_20bit>` and is a HINT nop. `lpad` +instruction must be aligned on 4 byte boundary and compares 20 bit immediate with x7. +If `imm_20bit` == 0, CPU don't perform any comparision with x7. If `imm_20bit` != 0, +then `imm_20bit` must match x7 else CPU will raise `software check exception` +(cause=18)with `*tval = 2`. + +Compiler can generate a hash over function signatures and setup them (truncated +to 20bit) in x7 at callsites and function proglogs 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. + +3. Linux enabling +------------------ + +User space programs can have multiple shared objects loaded in its address space +and it's a difficult task to make sure all the dependencies have been compiled +with support of indirect branch. Thus it's left to dynamic loader to enable +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 branch +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 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 with `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 tracking. +If enabled it'll return `PR_INDIR_BR_LP_ENABLE` + +`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 posture 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 +-------------------------------------------------- + +Pertaining to indirect branch tracking, CPU raises software check exception 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 = 2` is captured and software check exception is raised +(cause=18) + +Linux kernel will treat this as `SIGSEV`` with code = `SEGV_CPERR` and follow +normal course of signal delivery. -- 2.43.2
WARNING: multiple messages have this Message-ID (diff)
From: Deepak Gupta <debug@rivosinc.com> To: paul.walmsley@sifive.com, rick.p.edgecombe@intel.com, broonie@kernel.org, Szabolcs.Nagy@arm.com, kito.cheng@sifive.com, keescook@chromium.org, ajones@ventanamicro.com, conor.dooley@microchip.com, cleger@rivosinc.com, atishp@atishpatra.org, alex@ghiti.fr, bjorn@rivosinc.com, alexghiti@rivosinc.com, samuel.holland@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-mm@kvack.org, linux-arch@vger.kernel.org, linux-kselftest@vger.kernel.org Cc: corbet@lwn.net, tech-j-ext@lists.risc-v.org, palmer@dabbelt.com, aou@eecs.berkeley.edu, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, oleg@redhat.com, akpm@linux-foundation.org, arnd@arndb.de, ebiederm@xmission.com, Liam.Howlett@oracle.com, vbabka@suse.cz, lstoakes@gmail.com, shuah@kernel.org, brauner@kernel.org, debug@rivosinc.com, andy.chiu@sifive.com, jerry.shih@sifive.com, hankuan.chen@sifive.com, greentime.hu@sifive.com, evan@rivosinc.com, xiao.w.wang@intel.com, charlie@rivosinc.com, apatel@ventanamicro.com, mchitale@ventanamicro.com, dbarboza@ventanamicro.com, sameo@rivosinc.com, shikemeng@huaweicloud.com, willy@infradead.org, vincent.chen@sifive.com, guoren@kernel.org, samitolvanen@google.com, songshuaishuai@tinylab.org, gerg@kernel.org, heiko@sntech.de, bhe@redhat.com, jeeheng.sia@starfivetech.com, cyy@cyyself.name, maskray@google.com, ancientmodern4@gmail.com, mathis.salmen@matsal.de, cuiyunhui@bytedance.com, bgray@linux.ibm.com, mpe@ellerman.id.au, baruch@tkos.co.il, alx@kernel.org, david@redhat.com, catalin.marinas@arm.com, revest@chromium.org, josh@joshtriplett.org, shr@devkernel.io, deller@gmx.de, omosnace@redhat.com, ojeda@kernel.org, jhubbard@nvidia.com Subject: [PATCH v2 25/27] riscv: Documentation for landing pad / indirect branch tracking Date: Thu, 28 Mar 2024 21:44:57 -0700 [thread overview] Message-ID: <20240329044459.3990638-26-debug@rivosinc.com> (raw) In-Reply-To: <20240329044459.3990638-1-debug@rivosinc.com> 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 <debug@rivosinc.com> --- Documentation/arch/riscv/zicfilp.rst | 104 +++++++++++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 Documentation/arch/riscv/zicfilp.rst diff --git a/Documentation/arch/riscv/zicfilp.rst b/Documentation/arch/riscv/zicfilp.rst new file mode 100644 index 000000000000..3007c81f0465 --- /dev/null +++ b/Documentation/arch/riscv/zicfilp.rst @@ -0,0 +1,104 @@ +.. SPDX-License-Identifier: GPL-2.0 + +:Author: Deepak Gupta <debug@rivosinc.com> +:Date: 12 January 2024 + +==================================================== +Tracking indirect control transfers on RISC-V Linux +==================================================== + +This document briefly describes the interface provided to userspace by Linux +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 hands of +an adversary and if used creatively can result into variety security issues. + +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 jump oriented +programming (JOP) or call oriented programming (COP) and thus compromising 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 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`. + There are two exception to this rule + - rs1 = x1 or rs1 = x5, i.e. a return from a function and returns are + protected using shadow stack (see zicfiss.rst) + + - rs1 = x7. On RISC-V compiler usually does below to reach function + which is beyond the offset possible J-type instruction. + + "auipc x7, <imm>" + "jalr (x7)" + + Such form of indirect control transfer are still immutable and don't rely + on memory and thus rs1=x7 is exempted from tracking and considered software + guarded jumps. + +`lpad` instruction is pseudo of `auipc rd, <imm_20bit>` and is a HINT nop. `lpad` +instruction must be aligned on 4 byte boundary and compares 20 bit immediate with x7. +If `imm_20bit` == 0, CPU don't perform any comparision with x7. If `imm_20bit` != 0, +then `imm_20bit` must match x7 else CPU will raise `software check exception` +(cause=18)with `*tval = 2`. + +Compiler can generate a hash over function signatures and setup them (truncated +to 20bit) in x7 at callsites and function proglogs 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. + +3. Linux enabling +------------------ + +User space programs can have multiple shared objects loaded in its address space +and it's a difficult task to make sure all the dependencies have been compiled +with support of indirect branch. Thus it's left to dynamic loader to enable +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 branch +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 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 with `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 tracking. +If enabled it'll return `PR_INDIR_BR_LP_ENABLE` + +`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 posture 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 +-------------------------------------------------- + +Pertaining to indirect branch tracking, CPU raises software check exception 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 = 2` is captured and software check exception is raised +(cause=18) + +Linux kernel will treat this as `SIGSEV`` with code = `SEGV_CPERR` and follow +normal course of signal delivery. -- 2.43.2 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2024-03-29 4:47 UTC|newest] Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-29 4:44 [PATCH v2 00/27] riscv control-flow integrity for usermode Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 01/27] riscv: envcfg save and restore on task switching Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 02/27] riscv: define default value for envcfg Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 03/27] riscv/Kconfig: enable HAVE_EXIT_THREAD for riscv Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 04/27] riscv: zicfiss/zicfilp enumeration Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 5:08 ` Stefan O'Rear 2024-03-29 5:08 ` Stefan O'Rear 2024-03-29 5:13 ` Deepak Gupta 2024-03-29 5:13 ` Deepak Gupta 2024-03-29 7:24 ` Conor Dooley 2024-03-29 7:24 ` Conor Dooley 2024-03-29 4:44 ` [PATCH v2 05/27] riscv: zicfiss/zicfilp extension csr and bit definitions Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 06/27] riscv: usercfi state for task and save/restore of CSR_SSP on trap entry/exit Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 07/27] mm: Define VM_SHADOW_STACK for RISC-V Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 08/27] mm: abstract shadow stack vma behind `arch_is_shadow_stack` Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 09/27] riscv/mm : ensure PROT_WRITE leads to VM_READ | VM_WRITE Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 10/27] riscv mm: manufacture shadow stack pte Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 11/27] riscv mmu: teach pte_mkwrite to manufacture shadow stack PTEs Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 5:15 ` Deepak Gupta 2024-03-29 5:15 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 12/27] riscv mmu: write protect and shadow stack Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 13/27] riscv/mm: Implement map_shadow_stack() syscall Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 14/27] riscv/shstk: If needed allocate a new shadow stack on clone Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 15/27] prctl: arch-agnostic prctl for shadow stack Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 16/27] prctl: arch-agnostic prtcl for indirect branch tracking Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 17/27] riscv: Implements arch agnostic shadow stack prctls Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 18/27] riscv: Implements arch argnostic indirect branch tracking prctls Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 19/27] riscv/kernel: update __show_regs to print shadow stack register Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 20/27] riscv/traps: Introduce software check exception Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 21/27] riscv sigcontext: adding cfi state field in sigcontext Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 22/27] riscv signal: Save and restore of shadow stack for signal Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 23/27] riscv/ptrace: riscv cfi status and state via ptrace and in core files Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 24/27] riscv: create a config for shadow stack and landing pad instr support Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta [this message] 2024-03-29 4:44 ` [PATCH v2 25/27] riscv: Documentation for landing pad / indirect branch tracking Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 26/27] riscv: Documentation for shadow stack on riscv Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 4:44 ` [PATCH v2 27/27] kselftest/riscv: kselftest for user mode cfi Deepak Gupta 2024-03-29 4:44 ` Deepak Gupta 2024-03-29 19:50 ` Muhammad Usama Anjum 2024-03-29 19:50 ` Muhammad Usama Anjum 2024-03-29 20:02 ` Deepak Gupta 2024-03-29 20:02 ` Deepak Gupta 2024-04-01 9:46 ` Muhammad Usama Anjum 2024-04-01 9:46 ` Muhammad Usama Anjum 2024-04-01 17:34 ` Deepak Gupta 2024-04-01 17:34 ` Deepak Gupta 2024-04-01 17:55 ` Deepak Gupta 2024-04-01 17:55 ` Deepak Gupta
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20240329044459.3990638-26-debug@rivosinc.com \ --to=debug@rivosinc.com \ --cc=Liam.Howlett@oracle.com \ --cc=Szabolcs.Nagy@arm.com \ --cc=ajones@ventanamicro.com \ --cc=akpm@linux-foundation.org \ --cc=alex@ghiti.fr \ --cc=alexghiti@rivosinc.com \ --cc=alx@kernel.org \ --cc=ancientmodern4@gmail.com \ --cc=andy.chiu@sifive.com \ --cc=aou@eecs.berkeley.edu \ --cc=apatel@ventanamicro.com \ --cc=arnd@arndb.de \ --cc=atishp@atishpatra.org \ --cc=baruch@tkos.co.il \ --cc=bgray@linux.ibm.com \ --cc=bhe@redhat.com \ --cc=bjorn@rivosinc.com \ --cc=brauner@kernel.org \ --cc=broonie@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=charlie@rivosinc.com \ --cc=cleger@rivosinc.com \ --cc=conor.dooley@microchip.com \ --cc=conor@kernel.org \ --cc=corbet@lwn.net \ --cc=cuiyunhui@bytedance.com \ --cc=cyy@cyyself.name \ --cc=david@redhat.com \ --cc=dbarboza@ventanamicro.com \ --cc=deller@gmx.de \ --cc=devicetree@vger.kernel.org \ --cc=ebiederm@xmission.com \ --cc=evan@rivosinc.com \ --cc=gerg@kernel.org \ --cc=greentime.hu@sifive.com \ --cc=guoren@kernel.org \ --cc=hankuan.chen@sifive.com \ --cc=heiko@sntech.de \ --cc=jeeheng.sia@starfivetech.com \ --cc=jerry.shih@sifive.com \ --cc=jhubbard@nvidia.com \ --cc=josh@joshtriplett.org \ --cc=keescook@chromium.org \ --cc=kito.cheng@sifive.com \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-kselftest@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-riscv@lists.infradead.org \ --cc=lstoakes@gmail.com \ --cc=maskray@google.com \ --cc=mathis.salmen@matsal.de \ --cc=mchitale@ventanamicro.com \ --cc=mpe@ellerman.id.au \ --cc=ojeda@kernel.org \ --cc=oleg@redhat.com \ --cc=omosnace@redhat.com \ --cc=palmer@dabbelt.com \ --cc=palmer@sifive.com \ --cc=paul.walmsley@sifive.com \ --cc=revest@chromium.org \ --cc=rick.p.edgecombe@intel.com \ --cc=robh+dt@kernel.org \ --cc=sameo@rivosinc.com \ --cc=samitolvanen@google.com \ --cc=samuel.holland@sifive.com \ --cc=shikemeng@huaweicloud.com \ --cc=shr@devkernel.io \ --cc=shuah@kernel.org \ --cc=songshuaishuai@tinylab.org \ --cc=tech-j-ext@lists.risc-v.org \ --cc=vbabka@suse.cz \ --cc=vincent.chen@sifive.com \ --cc=willy@infradead.org \ --cc=xiao.w.wang@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.