Re: [PATCH V6 09/11] riscv: Add support for STACKLEAK gcc plugin
From: Guo Ren
Date: Fri Oct 07 2022 - 20:16:57 EST
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