On Mon, Oct 3, 2022 at 7:34 PM Mark Rutland <mark.rutland@xxxxxxx> wrote: > > On Sat, Oct 01, 2022 at 09:24:49PM -0400, guoren@xxxxxxxxxx wrote: > > From: Dao Lu <daolu@xxxxxxxxxxxx> > > > > Add support for STACKLEAK gcc plugin to riscv by implementing > > stackleak_check_alloca, based heavily on the arm64 version, and > > modifying the entry.S. Additionally, this disables the plugin for EFI > > stub code for riscv. All modifications base on generic_entry. > > I think this commit message is stale; `stackleak_check_alloca` doesn't exist > any more. > > > Link: https://lore.kernel.org/linux-riscv/20220615213834.3116135-1-daolu@xxxxxxxxxxxx/ > > Signed-off-by: Dao Lu <daolu@xxxxxxxxxxxx> > > Co-developed-by: Xianting Tian <xianting.tian@xxxxxxxxxxxxxxxxx> > > Signed-off-by: Xianting Tian <xianting.tian@xxxxxxxxxxxxxxxxx> > > Co-developed-by: Guo Ren <guoren@xxxxxxxxxx> > > Signed-off-by: Guo Ren <guoren@xxxxxxxxxx> > > Cc: Conor Dooley <Conor.Dooley@xxxxxxxxxxxxx> > > Cc: Mark Rutland <mark.rutland@xxxxxxx> > > --- > > arch/riscv/Kconfig | 1 + > > arch/riscv/kernel/entry.S | 8 +++++++- > > drivers/firmware/efi/libstub/Makefile | 2 +- > > 3 files changed, 9 insertions(+), 2 deletions(-) > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > > index dfe600f3526c..76bde12d9f8c 100644 > > --- a/arch/riscv/Kconfig > > +++ b/arch/riscv/Kconfig > > @@ -81,6 +81,7 @@ config RISCV > > select HAVE_ARCH_MMAP_RND_BITS if MMU > > select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT > > select HAVE_ARCH_SECCOMP_FILTER > > + select HAVE_ARCH_STACKLEAK > > select HAVE_ARCH_TRACEHOOK > > select HAVE_ARCH_TRANSPARENT_HUGEPAGE if 64BIT && MMU > > select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE > > diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S > > index 5f49517cd3a2..39097c1474a0 100644 > > --- a/arch/riscv/kernel/entry.S > > +++ b/arch/riscv/kernel/entry.S > > @@ -130,7 +130,6 @@ END(handle_exception) > > ENTRY(ret_from_exception) > > REG_L s0, PT_STATUS(sp) > > > > - csrc CSR_STATUS, SR_IE > > #ifdef CONFIG_RISCV_M_MODE > > /* the MPP value is too large to be used as an immediate arg for addi */ > > li t0, SR_MPP > > @@ -139,6 +138,9 @@ ENTRY(ret_from_exception) > > andi s0, s0, SR_SPP > > #endif > > bnez s0, 1f > > +#ifdef CONFIG_GCC_PLUGIN_STACKLEAK > > + call stackleak_erase > > +#endif > > I assume this can happen on an arbitrary stack, and so you can't use the > stackleak_erase_{on,off}_task_stack variants? Dao Lu first patch: call stackleak_erase in resume_userspace Xianting second patch: call stackleak_erase only in resume_syscall I just thought Dao Lu was right, so I included his patch. Your comment is to let it call stackleak_erase in all ret_from_exception because stack leak may have happened "the day before yesterday"/nested interrupt context, right? So we need to clean up all the stacks. Here is the new modification: diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S index 5f49517cd3a2..39097c1474a0 100644 --- a/arch/riscv/kernel/entry.S +++ b/arch/riscv/kernel/entry.S @@ -130,7 +130,6 @@ END(handle_exception) ENTRY(ret_from_exception) +#ifdef CONFIG_GCC_PLUGIN_STACKLEAK + call stackleak_erase +#endif REG_L s0, PT_STATUS(sp) csrc CSR_STATUS, SR_IE #ifdef CONFIG_RISCV_M_MODE /* the MPP value is too large to be used as an immediate arg for addi */ li t0, SR_MPP @@ -139,6 +138,9 @@ ENTRY(ret_from_exception) andi s0, s0, SR_SPP #endif bnez s0, 1f /* Save unwound kernel stack pointer in thread_info */ addi s0, sp, PT_SIZE_ON_STACK @@ -148,8 +150,12 @@ ENTRY(ret_from_exception) * Save TP into the scratch register , so we can find the kernel data * structures again. */ csrw CSR_SCRATCH, tp 1: > > Just to check, have you given this a spin with LKDTM and the STACKLEAK_ERASING > test? If not, it'd be good to test that (and ideally, put some sample output > from that into the commit message). Okay, I would. > > For example, as per: > > https://lore.kernel.org/all/20220427173128.2603085-1-mark.rutland@xxxxxxx/ > > ... on arm64 this looks something like: > > | # uname -a > | Linux buildroot 5.18.0-rc1-00013-g26f638ab0d7c #3 SMP PREEMPT Wed Apr 27 16:21:37 BST 2022 aarch64 GNU/Linux > | # echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT > | lkdtm: Performing direct entry STACKLEAK_ERASING > | lkdtm: stackleak stack usage: > | high offset: 336 bytes > | current: 688 bytes > | lowest: 1232 bytes > | tracked: 1232 bytes > | untracked: 672 bytes > | poisoned: 14136 bytes > | low offset: 8 bytes > | lkdtm: OK: the rest of the thread stack is properly erased > > Thanks, > Mark. > > > > > /* Save unwound kernel stack pointer in thread_info */ > > addi s0, sp, PT_SIZE_ON_STACK > > @@ -148,8 +150,12 @@ ENTRY(ret_from_exception) > > * Save TP into the scratch register , so we can find the kernel data > > * structures again. > > */ > > + csrc CSR_STATUS, SR_IE > > csrw CSR_SCRATCH, tp > > + j 2f > > 1: > > + csrc CSR_STATUS, SR_IE > > +2: > > /* > > * The current load reservation is effectively part of the processor's > > * state, in the sense that load reservations cannot be shared between > > diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile > > index d0537573501e..5e1fc4f82883 100644 > > --- a/drivers/firmware/efi/libstub/Makefile > > +++ b/drivers/firmware/efi/libstub/Makefile > > @@ -25,7 +25,7 @@ cflags-$(CONFIG_ARM) := $(subst $(CC_FLAGS_FTRACE),,$(KBUILD_CFLAGS)) \ > > -fno-builtin -fpic \ > > $(call cc-option,-mno-single-pic-base) > > cflags-$(CONFIG_RISCV) := $(subst $(CC_FLAGS_FTRACE),,$(KBUILD_CFLAGS)) \ > > - -fpic > > + -fpic $(DISABLE_STACKLEAK_PLUGIN) > > > > cflags-$(CONFIG_EFI_GENERIC_STUB) += -I$(srctree)/scripts/dtc/libfdt > > > > -- > > 2.36.1 > > -- Best Regards Guo Ren
