1. Patchew
  2. linux
  3. [PATCH V6 00/11] riscv: Add GENERIC_ENTRY support and related features
  4. View patch

[PATCH V6 09/11] riscv: Add support for STACKLEAK gcc plugin

guoren@kernel.org posted 11 patches 3 years, 6 months ago
There is a newer version of this series
[PATCH V6 09/11] riscv: Add support for STACKLEAK gcc plugin
Posted by guoren@kernel.org 3 years, 6 months ago 
From: Dao Lu <daolu@rivosinc.com>

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.

Link: https://lore.kernel.org/linux-riscv/20220615213834.3116135-1-daolu@rivosinc.com/
Signed-off-by: Dao Lu <daolu@rivosinc.com>
Co-developed-by: Xianting Tian <xianting.tian@linux.alibaba.com>
Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
Co-developed-by: Guo Ren <guoren@kernel.org>
Signed-off-by: Guo Ren <guoren@kernel.org>
Cc: Conor Dooley <Conor.Dooley@microchip.com>
Cc: Mark Rutland <mark.rutland@arm.com>
---
 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
 
 	/* 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
Re: [PATCH V6 09/11] riscv: Add support for STACKLEAK gcc plugin
Posted by Mark Rutland 3 years, 6 months ago 
On Sat, Oct 01, 2022 at 09:24:49PM -0400, guoren@kernel.org wrote:
> From: Dao Lu <daolu@rivosinc.com>
> 
> 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@rivosinc.com/
> Signed-off-by: Dao Lu <daolu@rivosinc.com>
> Co-developed-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> Co-developed-by: Guo Ren <guoren@kernel.org>
> Signed-off-by: Guo Ren <guoren@kernel.org>
> Cc: Conor Dooley <Conor.Dooley@microchip.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> ---
>  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?

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).

For example, as per:

  https://lore.kernel.org/all/20220427173128.2603085-1-mark.rutland@arm.com/

... 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
>
Re: [PATCH V6 09/11] riscv: Add support for STACKLEAK gcc plugin
Posted by Guo Ren 3 years, 6 months ago 
On Mon, Oct 3, 2022 at 7:34 PM Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Sat, Oct 01, 2022 at 09:24:49PM -0400, guoren@kernel.org wrote:
> > From: Dao Lu <daolu@rivosinc.com>
> >
> > 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@rivosinc.com/
> > Signed-off-by: Dao Lu <daolu@rivosinc.com>
> > Co-developed-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> > Co-developed-by: Guo Ren <guoren@kernel.org>
> > Signed-off-by: Guo Ren <guoren@kernel.org>
> > Cc: Conor Dooley <Conor.Dooley@microchip.com>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > ---
> >  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?
I misunderstood before.

Yes, riscv could use stackleak_erase_on_task_stack. Because the sp has
changed to task_stack, even when irq/soft_irq.

>
> 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).
>
> For example, as per:
>
>   https://lore.kernel.org/all/20220427173128.2603085-1-mark.rutland@arm.com/
>
> ... 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
Re: [PATCH V6 09/11] riscv: Add support for STACKLEAK gcc plugin
Posted by Guo Ren 3 years, 6 months ago 
Hi Mark,

Here is the test result with stackleak_erase_on_task_stack.

# echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT
[   53.110405] lkdtm: Performing direct entry STACKLEAK_ERASING
[   53.111630] lkdtm: stackleak stack usage:
[   53.111630]   high offset: 288 bytes
[   53.111630]   current:     592 bytes
[   53.111630]   lowest:      1136 bytes
[   53.111630]   tracked:     1136 bytes
[   53.111630]   untracked:   576 bytes
[   53.111630]   poisoned:    14376 bytes
[   53.111630]   low offset:  8 bytes
[   53.115078] lkdtm: OK: the rest of the thread stack is properly erased

On Sat, Oct 8, 2022 at 11:26 AM Guo Ren <guoren@kernel.org> wrote:
>
> On Mon, Oct 3, 2022 at 7:34 PM Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > On Sat, Oct 01, 2022 at 09:24:49PM -0400, guoren@kernel.org wrote:
> > > From: Dao Lu <daolu@rivosinc.com>
> > >
> > > 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@rivosinc.com/
> > > Signed-off-by: Dao Lu <daolu@rivosinc.com>
> > > Co-developed-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> > > Co-developed-by: Guo Ren <guoren@kernel.org>
> > > Signed-off-by: Guo Ren <guoren@kernel.org>
> > > Cc: Conor Dooley <Conor.Dooley@microchip.com>
> > > Cc: Mark Rutland <mark.rutland@arm.com>
> > > ---
> > >  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?
> I misunderstood before.
>
> Yes, riscv could use stackleak_erase_on_task_stack. Because the sp has
> changed to task_stack, even when irq/soft_irq.
>
> >
> > 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).
> >
> > For example, as per:
> >
> >   https://lore.kernel.org/all/20220427173128.2603085-1-mark.rutland@arm.com/
> >
> > ... 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



-- 
Best Regards
 Guo Ren
Re: [PATCH V6 09/11] riscv: Add support for STACKLEAK gcc plugin
Posted by Guo Ren 3 years, 6 months ago 
On Mon, Oct 3, 2022 at 7:34 PM Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Sat, Oct 01, 2022 at 09:24:49PM -0400, guoren@kernel.org wrote:
> > From: Dao Lu <daolu@rivosinc.com>
> >
> > 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@rivosinc.com/
> > Signed-off-by: Dao Lu <daolu@rivosinc.com>
> > Co-developed-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> > Co-developed-by: Guo Ren <guoren@kernel.org>
> > Signed-off-by: Guo Ren <guoren@kernel.org>
> > Cc: Conor Dooley <Conor.Dooley@microchip.com>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > ---
> >  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@arm.com/
>
> ... 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

Patchew 2.1-devel-ea86937

© 2016 - 2026 Red Hat, Inc.