linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Deepak Gupta <debug@rivosinc.com>
To: Stefan O'Rear <sorear@fastmail.com>
Cc: rick.p.edgecombe@intel.com, broonie@kernel.org,
	Szabolcs.Nagy@arm.com,
	"kito.cheng@sifive.com" <kito.cheng@sifive.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Andrew Jones" <ajones@ventanamicro.com>,
	paul.walmsley@sifive.com, "Palmer Dabbelt" <palmer@dabbelt.com>,
	"Conor Dooley" <conor.dooley@microchip.com>,
	cleger@rivosinc.com, "Atish Patra" <atishp@atishpatra.org>,
	"Alexandre Ghiti" <alex@ghiti.fr>,
	"Björn Töpel" <bjorn@rivosinc.com>,
	"Alexandre Ghiti" <alexghiti@rivosinc.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	oleg@redhat.com, akpm@linux-foundation.org, arnd@arndb.de,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	shuah@kernel.org, "Christian Brauner" <brauner@kernel.org>,
	guoren <guoren@kernel.org>,
	samitolvanen@google.com, "Evan Green" <evan@rivosinc.com>,
	xiao.w.wang@intel.com, "Anup Patel" <apatel@ventanamicro.com>,
	mchitale@ventanamicro.com, waylingii@gmail.com,
	greentime.hu@sifive.com, "Heiko Stuebner" <heiko@sntech.de>,
	"Jisheng Zhang" <jszhang@kernel.org>,
	shikemeng@huaweicloud.com, "David Hildenbrand" <david@redhat.com>,
	"Charlie Jenkins" <charlie@rivosinc.com>,
	panqinglin2020@iscas.ac.cn, willy@infradead.org,
	"Vincent Chen" <vincent.chen@sifive.com>,
	"Andy Chiu" <andy.chiu@sifive.com>,
	"Greg Ungerer" <gerg@kernel.org>,
	jeeheng.sia@starfivetech.com, mason.huo@starfivetech.com,
	ancientmodern4@gmail.com, mathis.salmen@matsal.de,
	cuiyunhui@bytedance.com, "Baoquan He" <bhe@redhat.com>,
	chenjiahao16@huawei.com, ruscur@russell.cc, bgray@linux.ibm.com,
	alx@kernel.org, baruch@tkos.co.il, zhangqing@loongson.cn,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	revest@chromium.org, josh@joshtriplett.org, joey.gouly@arm.com,
	shr@devkernel.io, omosnace@redhat.com, ojeda@kernel.org,
	jhubbard@nvidia.com, linux-doc@vger.kernel.org,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-arch@vger.kernel.org,
	linux-kselftest@vger.kernel.org
Subject: Re: [RFC PATCH v1 07/28] riscv: kernel handling on trap entry/exit for user cfi
Date: Thu, 25 Jan 2024 16:25:15 -0800	[thread overview]
Message-ID: <ZbL7618N++ygHlM8@debug.ba.rivosinc.com> (raw)
In-Reply-To: <153fe34e-ba56-478e-b0b9-ae85c6c945b5@app.fastmail.com>

On Thu, Jan 25, 2024 at 02:47:49PM -0500, Stefan O'Rear wrote:
>On Thu, Jan 25, 2024, at 12:30 PM, Deepak Gupta wrote:
>> On Thu, Jan 25, 2024 at 02:29:01AM -0500, Stefan O'Rear wrote:
>>>On Thu, Jan 25, 2024, at 1:21 AM, debug@rivosinc.com wrote:
>>>> From: Deepak Gupta <debug@rivosinc.com>
>>>>
>>>> Carves out space in arch specific thread struct for cfi status and shadow stack
>>>> in usermode on riscv.
>>>>
>>>> This patch does following
>>>> - defines a new structure cfi_status with status bit for cfi feature
>>>> - defines shadow stack pointer, base and size in cfi_status structure
>>>> - defines offsets to new member fields in thread in asm-offsets.c
>>>> - Saves and restore shadow stack pointer on trap entry (U --> S) and exit
>>>>   (S --> U)
>>>>
>>>> Signed-off-by: Deepak Gupta <debug@rivosinc.com>
>>>> ---
>>>>  arch/riscv/include/asm/processor.h   |  1 +
>>>>  arch/riscv/include/asm/thread_info.h |  3 +++
>>>>  arch/riscv/include/asm/usercfi.h     | 24 ++++++++++++++++++++++++
>>>>  arch/riscv/kernel/asm-offsets.c      |  5 ++++-
>>>>  arch/riscv/kernel/entry.S            | 25 +++++++++++++++++++++++++
>>>>  5 files changed, 57 insertions(+), 1 deletion(-)
>>>>  create mode 100644 arch/riscv/include/asm/usercfi.h
>>>>
>>>> diff --git a/arch/riscv/include/asm/processor.h
>>>> b/arch/riscv/include/asm/processor.h
>>>> index ee2f51787ff8..d4dc298880fc 100644
>>>> --- a/arch/riscv/include/asm/processor.h
>>>> +++ b/arch/riscv/include/asm/processor.h
>>>> @@ -14,6 +14,7 @@
>>>>
>>>>  #include <asm/ptrace.h>
>>>>  #include <asm/hwcap.h>
>>>> +#include <asm/usercfi.h>
>>>>
>>>>  #ifdef CONFIG_64BIT
>>>>  #define DEFAULT_MAP_WINDOW	(UL(1) << (MMAP_VA_BITS - 1))
>>>> diff --git a/arch/riscv/include/asm/thread_info.h
>>>> b/arch/riscv/include/asm/thread_info.h
>>>> index 320bc899a63b..6a2acecec546 100644
>>>> --- a/arch/riscv/include/asm/thread_info.h
>>>> +++ b/arch/riscv/include/asm/thread_info.h
>>>> @@ -58,6 +58,9 @@ struct thread_info {
>>>>  	int			cpu;
>>>>  	unsigned long		syscall_work;	/* SYSCALL_WORK_ flags */
>>>>  	unsigned long envcfg;
>>>> +#ifdef CONFIG_RISCV_USER_CFI
>>>> +	struct cfi_status       user_cfi_state;
>>>> +#endif
>>>>  #ifdef CONFIG_SHADOW_CALL_STACK
>>>>  	void			*scs_base;
>>>>  	void			*scs_sp;
>>>> diff --git a/arch/riscv/include/asm/usercfi.h
>>>> b/arch/riscv/include/asm/usercfi.h
>>>> new file mode 100644
>>>> index 000000000000..080d7077d12c
>>>> --- /dev/null
>>>> +++ b/arch/riscv/include/asm/usercfi.h
>>>> @@ -0,0 +1,24 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0
>>>> + * Copyright (C) 2023 Rivos, Inc.
>>>> + * Deepak Gupta <debug@rivosinc.com>
>>>> + */
>>>> +#ifndef _ASM_RISCV_USERCFI_H
>>>> +#define _ASM_RISCV_USERCFI_H
>>>> +
>>>> +#ifndef __ASSEMBLY__
>>>> +#include <linux/types.h>
>>>> +
>>>> +#ifdef CONFIG_RISCV_USER_CFI
>>>> +struct cfi_status {
>>>> +	unsigned long ubcfi_en : 1; /* Enable for backward cfi. */
>>>> +	unsigned long rsvd : ((sizeof(unsigned long)*8) - 1);
>>>> +	unsigned long user_shdw_stk; /* Current user shadow stack pointer */
>>>> +	unsigned long shdw_stk_base; /* Base address of shadow stack */
>>>> +	unsigned long shdw_stk_size; /* size of shadow stack */
>>>> +};
>>>> +
>>>> +#endif /* CONFIG_RISCV_USER_CFI */
>>>> +
>>>> +#endif /* __ASSEMBLY__ */
>>>> +
>>>> +#endif /* _ASM_RISCV_USERCFI_H */
>>>> diff --git a/arch/riscv/kernel/asm-offsets.c
>>>> b/arch/riscv/kernel/asm-offsets.c
>>>> index cdd8f095c30c..5e1f412e96ba 100644
>>>> --- a/arch/riscv/kernel/asm-offsets.c
>>>> +++ b/arch/riscv/kernel/asm-offsets.c
>>>> @@ -43,8 +43,11 @@ void asm_offsets(void)
>>>>  #ifdef CONFIG_SHADOW_CALL_STACK
>>>>  	OFFSET(TASK_TI_SCS_SP, task_struct, thread_info.scs_sp);
>>>>  #endif
>>>> -
>>>>  	OFFSET(TASK_TI_CPU_NUM, task_struct, thread_info.cpu);
>>>> +#ifdef CONFIG_RISCV_USER_CFI
>>>> +	OFFSET(TASK_TI_CFI_STATUS, task_struct, thread_info.user_cfi_state);
>>>> +	OFFSET(TASK_TI_USER_SSP, task_struct,
>>>> thread_info.user_cfi_state.user_shdw_stk);
>>>> +#endif
>>>>  	OFFSET(TASK_THREAD_F0,  task_struct, thread.fstate.f[0]);
>>>>  	OFFSET(TASK_THREAD_F1,  task_struct, thread.fstate.f[1]);
>>>>  	OFFSET(TASK_THREAD_F2,  task_struct, thread.fstate.f[2]);
>>>> diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
>>>> index 63c3855ba80d..410659e2eadb 100644
>>>> --- a/arch/riscv/kernel/entry.S
>>>> +++ b/arch/riscv/kernel/entry.S
>>>> @@ -49,6 +49,21 @@ SYM_CODE_START(handle_exception)
>>>>  	REG_S x5,  PT_T0(sp)
>>>>  	save_from_x6_to_x31
>>>>
>>>> +#ifdef CONFIG_RISCV_USER_CFI
>>>> +	/*
>>>> +	* we need to save cfi status only when previous mode was U
>>>> +	*/
>>>> +	csrr s2, CSR_STATUS
>>>> +	andi s2, s2, SR_SPP
>>>> +	bnez s2, skip_bcfi_save
>>>> +	/* load cfi status word */
>>>> +	lw s3, TASK_TI_CFI_STATUS(tp)
>>>> +	andi s3, s3, 1
>>>> +	beqz s3, skip_bcfi_save
>>>> +	csrr s3, CSR_SSP
>>>> +	REG_S s3, TASK_TI_USER_SSP(tp) /* save user ssp in thread_info */
>>>> +skip_bcfi_save:
>>>> +#endif
>>>>  	/*
>>>>  	 * Disable user-mode memory access as it should only be set in the
>>>>  	 * actual user copy routines.
>>>> @@ -141,6 +156,16 @@ SYM_CODE_START_NOALIGN(ret_from_exception)
>>>>  	 * structures again.
>>>>  	 */
>>>>  	csrw CSR_SCRATCH, tp
>>>> +
>>>> +#ifdef CONFIG_RISCV_USER_CFI
>>>> +	lw s3, TASK_TI_CFI_STATUS(tp)
>>>> +	andi s3, s3, 1
>>>> +	beqz s3, skip_bcfi_resume
>>>> +	REG_L s3, TASK_TI_USER_SSP(tp) /* restore user ssp from thread struct */
>>>> +	csrw CSR_SSP, s3
>>>> +skip_bcfi_resume:
>>>> +#endif
>>>> +
>>>
>>>We shouldn't need any of this in the entry/exit code, at least as long as
>>>the kernel itself is not using Zicfiss.  ssp can keep its value in the
>>>kernel and swap it on task switches.  Our entry/exit code is rather short
>>>and I'd like to keep it that way.
>>
>> I kept it here because sooner or later we will need to establish kernel
>> shadow
>> stack. Kernel shadow stack on riscv (compared to other arches) kernel
>> actually will
>> be easier to support and adopt because there is already support for
>> shadow call stack
>> (SCS, [1]). Difference between existing shadow call stack (SCS) and
>> `zicfiss` based
>> kernel shadow stack would be
>>
>> 	- In prolog instead of using `sd`, we will be inserting `sspush` to
>> save ret addr
>> 	- In epilog instead of using `ld` and compare, we will be inserting
>> `sspopchk`
>>
>> So a lot underlying work and functional testing for shadow kernel stack
>> is already carried
>> out with SCS patches. It would be easier and faster to re-use SCS
>> patches to support
>> `zicfiss` based shadow stack.
>
>Do you think that realistically, after all the patches are merged, almost all
>kernel configurations that enable kernel Zicfiss will also enable userspace
>Zicfiss and vice versa?
>
>If not - if Zicfiss exclusively in user mode is likely to be a common
>configuration - then the kernel should handle that case in task switch.
>
>If kernel Zicfiss and user Zicfiss are overwhelmingly likely to be supported
>together, then I agree it makes sense to handle it in the same place in
>entry/exit, but I think what you have is more complicated than necessary.
>I'm picturing something like this:

I expect user mode would be the first target and even if kernel shadow stacks
are enabled, it may not be as pervasive in adoption as I expect for user mode.

I do expect it to be used in settings where both are enabled (if not overwhelmingly)

Since that has to be supported, it's better to have it organized where we are saving/
restoring in a way which serves both needs rather than have two ways to save/restore
depending on how user shadow stacks and kernel shadow stacks are configured.

>
>--- a/arch/riscv/kernel/entry.S
>+++ b/arch/riscv/kernel/entry.S
>@@ -32,6 +32,13 @@ SYM_CODE_START(handle_exception)
>        csrr tp, CSR_SCRATCH
>        REG_S sp, TASK_TI_KERNEL_SP(tp)
>
>+#ifdef CONFIG_SHADOW_CALL_STACK
>+       ALTERNATIVE("scs_save_current\n\tnop\n\tnop",
>+                    "csrr sp, ssp\n\t"
>+                   "REG_S sp, TASK_TI_SCS_SP(tp)\n\t"
>+                    "REG_L sp, TASK_TI_KERNEL_SP(tp)")
>+#endif
>+
> #ifdef CONFIG_VMAP_STACK
>        addi sp, sp, -(PT_SIZE_ON_STACK)
>        srli sp, sp, THREAD_SHIFT
>@@ -80,8 +87,13 @@ SYM_CODE_START(handle_exception)
>        /* Load the global pointer */
>        load_global_pointer
>
>-       /* Load the kernel shadow call stack pointer if coming from userspace */
>-       scs_load_current_if_task_changed s5
>+       /* Load the kernel shadow call stack pointer (harmless if from kernel) */
>+#ifdef CONFIG_SHADOW_CALL_STACK
>+       ALTERNATIVE("scs_load_current\n\tnop\n\tnop",
>+                    "REG_L s0, TASK_TI_SCS_SP(tp)\n\t"
>+                    "csrrw s0, ssp, s0\n\t"
>+                    "REG_S s0, PT_SSP(sp)")
>+#endif
>
>        move a0, sp /* pt_regs */
>        la ra, ret_from_exception
>@@ -130,7 +142,12 @@ SYM_CODE_START_NOALIGN(ret_from_exception)
>        REG_S s0, TASK_TI_KERNEL_SP(tp)
>
>        /* Save the kernel shadow call stack pointer */
>-       scs_save_current
>+#ifdef CONFIG_SHADOW_CALL_STACK
>+       ALTERNATIVE("scs_save_current\n\tnop\n\tnop",
>+                    "REG_L s0, PT_SSP(sp)\n\t"
>+                    "csrrw s0, ssp, s0\n\t"
>+                    "REG_S s0, TASK_TI_SCS_SP(tp)")
>+#endif

I've not used alternatives earlier. But yes along with kernel shadow stack
this is much more appealing. Let me munch on it a bit. 

>
>        /*
>         * Save TP into the scratch register , so we can find the kernel data
>
>
>I moved the shadow stack pointer into pt_regs because it's nearly a GPR and has a
>meaningfully different value on every trap; this allows us to talk about the ssp
>at the time of a trap in kernel mode.

I had been under the impression that changing `pt_regs` is something that we don't
do usually. If it doesn't require a high bar, I'll do that. Infact, one my earlier
implementation had ssp in pt_regs.

>
>Saving both the sp and ssp in Lrestore_kernel_tpsp avoids adding conditional logic
>to Lsave_context.  I believe the current code also has a bug: if the U-mode tp is,
>by chance or intentional exploit, equal to the thread_info address, kernel code
>will be executed with whatever value U-mode left in gp.
>
>I also notice that there is no check for overflow of the shadow stack.  This may be
>intentional, since as long as the shadow stack is at least half the size of the
>main kernel stack the latter will always overflow first, barring deeper corruption
>of the control structures or assembly code issues.  I expect that the result in that
>case would be an infinite loop of shadow stack overflows in handle_bad_stack and
>do_trap_software_check with occasional visits to handle_kernel_stack_overflow.
>
>I believe that "Save unwound kernel stack pointer in thread_info" and "Save the
>kernel shadow call stack pointer" are both no-ops in all cases other than ret_from_fork,
>since the ABI requires the C trap handler to return with the same sp and ssp it
>was entered with.  Optimizing that would be a separate issue.
>
>-s
>
>>
>> I don't have favorites here, if overwhelving opinion of community here
>> is to take this
>> logic into task switching and re-work this logic back into entry.S
>> whenever shadow stack for
>> kernel patches are posted, I can do that as well.
>>
>> [1] -
>> https://lore.kernel.org/all/20230828195833.756747-8-samitolvanen@google.com/
>>
>>>
>>>-s
>>>
>>>>  1:
>>>>  	REG_L a0, PT_STATUS(sp)
>>>>  	/*
>>>> --
>>>> 2.43.0
>>>>
>>>>
>>>> _______________________________________________
>>>> linux-riscv mailing list
>>>> linux-riscv@lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv


  reply	other threads:[~2024-01-26  0:25 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-25  6:21 [RFC PATCH v1 00/28] riscv control-flow integrity for usermode debug
2024-01-25  6:21 ` [RFC PATCH v1 01/28] riscv: abstract envcfg CSR debug
2024-02-12 10:23   ` Andrew Jones
2024-01-25  6:21 ` [RFC PATCH v1 02/28] riscv: envcfg save and restore on trap entry/exit debug
2024-01-25  7:19   ` Stefan O'Rear
2024-01-25 17:09     ` Deepak Gupta
2024-01-25 17:54       ` Deepak Gupta
2024-01-25  6:21 ` [RFC PATCH v1 03/28] riscv: define default value for envcfg debug
2024-01-25  6:21 ` [RFC PATCH v1 04/28] riscv/Kconfig: enable HAVE_EXIT_THREAD for riscv debug
2024-01-25  6:21 ` [RFC PATCH v1 05/28] riscv: zicfiss/zicfilp enumeration debug
2024-01-25 17:59   ` Conor Dooley
2024-01-25 18:26     ` Deepak Gupta
2024-01-25 18:46       ` Conor Dooley
2024-01-25  6:21 ` [RFC PATCH v1 06/28] riscv: zicfiss/zicfilp extension csr and bit definitions debug
2024-01-25  6:21 ` [RFC PATCH v1 07/28] riscv: kernel handling on trap entry/exit for user cfi debug
2024-01-25  7:29   ` Stefan O'Rear
2024-01-25 17:30     ` Deepak Gupta
2024-01-25 19:47       ` Stefan O'Rear
2024-01-26  0:25         ` Deepak Gupta [this message]
2024-01-25  6:21 ` [RFC PATCH v1 08/28] mm: Define VM_SHADOW_STACK for RISC-V debug
2024-01-25  8:17   ` David Hildenbrand
2024-01-25 17:05     ` Deepak Gupta
2024-01-25  6:21 ` [RFC PATCH v1 09/28] mm: abstract shadow stack vma behind `arch_is_shadow_stack` debug
2024-01-25  8:18   ` David Hildenbrand
2024-01-25 17:07     ` Deepak Gupta
2024-02-13 10:34       ` David Hildenbrand
2024-02-22  1:32         ` Deepak Gupta
2024-01-25  6:21 ` [RFC PATCH v1 10/28] riscv/mm : Introducing new protection flag "PROT_SHADOWSTACK" debug
2024-01-25  6:21 ` [RFC PATCH v1 11/28] riscv: Implementing "PROT_SHADOWSTACK" on riscv debug
     [not found]   ` <2914cf78e47010e195d963857b37807e8446e3be.camel@intel.com>
2024-02-22  0:39     ` Deepak Gupta
2024-01-25  6:21 ` [RFC PATCH v1 12/28] riscv mm: manufacture shadow stack pte debug
2024-01-25  6:21 ` [RFC PATCH v1 13/28] riscv mmu: teach pte_mkwrite to manufacture shadow stack PTEs debug
2024-01-25  6:21 ` [RFC PATCH v1 14/28] riscv mmu: write protect and shadow stack debug
2024-01-25  6:21 ` [RFC PATCH v1 15/28] riscv/mm: Implement map_shadow_stack() syscall debug
2024-01-25 21:24   ` Charlie Jenkins
2024-01-26  0:44     ` Deepak Gupta
2024-02-06 16:01   ` Mark Brown
2024-02-22  0:47     ` Deepak Gupta
2024-02-22 13:33       ` Mark Brown
     [not found]   ` <ba45e69f69851721419b84f1ff8b66a490f92c86.camel@intel.com>
2024-02-22  0:50     ` Deepak Gupta
2024-01-25  6:21 ` [RFC PATCH v1 16/28] riscv/shstk: If needed allocate a new shadow stack on clone debug
2024-01-25  6:21 ` [RFC PATCH v1 17/28] prctl: arch-agnostic prctl for shadow stack debug
2024-01-25  6:21 ` [RFC PATCH v1 18/28] prctl: arch-agnostic prtcl for indirect branch tracking debug
2024-02-06 16:13   ` Mark Brown
2024-02-22  0:42     ` Deepak Gupta
2024-01-25  6:21 ` [RFC PATCH v1 19/28] riscv: Implements arch agnostic shadow stack prctls debug
2024-01-25  6:21 ` [RFC PATCH v1 20/28] riscv: Implements arch argnostic indirect branch tracking prctls debug
2024-01-25  6:21 ` [RFC PATCH v1 21/28] riscv/traps: Introduce software check exception debug
2024-01-25  6:21 ` [RFC PATCH v1 22/28] riscv sigcontext: adding cfi state field in sigcontext debug
2024-01-25  6:21 ` [RFC PATCH v1 23/28] riscv signal: Save and restore of shadow stack for signal debug
2024-01-25  6:21 ` [RFC PATCH v1 24/28] riscv: select config for shadow stack and landing pad instr support debug
2024-01-25 18:04   ` Conor Dooley
2024-01-25 18:12     ` Deepak Gupta
2024-01-25 18:44       ` Conor Dooley
2024-01-25 19:26         ` Deepak Gupta
2024-01-25  6:21 ` [RFC PATCH v1 25/28] riscv/ptrace: riscv cfi status and state via ptrace and in core files debug
2024-01-25  6:21 ` [RFC PATCH v1 26/28] riscv: Documentation for landing pad / indirect branch tracking debug
2024-01-25  6:21 ` [RFC PATCH v1 27/28] riscv: Documentation for shadow stack on riscv debug
2024-01-25  6:21 ` [RFC PATCH v1 28/28] kselftest/riscv: kselftest for user mode cfi debug

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=ZbL7618N++ygHlM8@debug.ba.rivosinc.com \
    --to=debug@rivosinc.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=chenjiahao16@huawei.com \
    --cc=cleger@rivosinc.com \
    --cc=conor.dooley@microchip.com \
    --cc=corbet@lwn.net \
    --cc=cuiyunhui@bytedance.com \
    --cc=david@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=evan@rivosinc.com \
    --cc=gerg@kernel.org \
    --cc=greentime.hu@sifive.com \
    --cc=guoren@kernel.org \
    --cc=heiko@sntech.de \
    --cc=jeeheng.sia@starfivetech.com \
    --cc=jhubbard@nvidia.com \
    --cc=joey.gouly@arm.com \
    --cc=josh@joshtriplett.org \
    --cc=jszhang@kernel.org \
    --cc=keescook@chromium.org \
    --cc=kito.cheng@sifive.com \
    --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=mason.huo@starfivetech.com \
    --cc=mathis.salmen@matsal.de \
    --cc=mchitale@ventanamicro.com \
    --cc=ojeda@kernel.org \
    --cc=oleg@redhat.com \
    --cc=omosnace@redhat.com \
    --cc=palmer@dabbelt.com \
    --cc=panqinglin2020@iscas.ac.cn \
    --cc=paul.walmsley@sifive.com \
    --cc=revest@chromium.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=ruscur@russell.cc \
    --cc=samitolvanen@google.com \
    --cc=shikemeng@huaweicloud.com \
    --cc=shr@devkernel.io \
    --cc=shuah@kernel.org \
    --cc=sorear@fastmail.com \
    --cc=vincent.chen@sifive.com \
    --cc=waylingii@gmail.com \
    --cc=willy@infradead.org \
    --cc=xiao.w.wang@intel.com \
    --cc=zhangqing@loongson.cn \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox