linux-kernel - Re: [PATCH V6 09/11] riscv: Add support for STACKLEAK gcc plugin

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YzrI1QFMpHnhvDnI@FVFF77S0Q05N>
Date:   Mon, 3 Oct 2022 12:34:45 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     guoren@...nel.org
Cc:     arnd@...db.de, palmer@...osinc.com, tglx@...utronix.de,
        peterz@...radead.org, luto@...nel.org, conor.dooley@...rochip.com,
        heiko@...ech.de, jszhang@...nel.org, lazyparser@...il.com,
        falcon@...ylab.org, chenhuacai@...nel.org, apatel@...tanamicro.com,
        atishp@...shpatra.org, palmer@...belt.com,
        paul.walmsley@...ive.com, zouyipeng@...wei.com,
        bigeasy@...utronix.de, David.Laight@...lab.com,
        chenzhongjin@...wei.com, linux-arch@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
        Dao Lu <daolu@...osinc.com>,
        Xianting Tian <xianting.tian@...ux.alibaba.com>
Subject: Re: [PATCH V6 09/11] riscv: Add support for STACKLEAK gcc plugin

On Sat, Oct 01, 2022 at 09:24:49PM -0400, guoren@...nel.org wrote:
> From: Dao Lu <daolu@...osinc.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@...osinc.com>
> Co-developed-by: Xianting Tian <xianting.tian@...ux.alibaba.com>
> Signed-off-by: Xianting Tian <xianting.tian@...ux.alibaba.com>
> Co-developed-by: Guo Ren <guoren@...nel.org>
> Signed-off-by: Guo Ren <guoren@...nel.org>
> Cc: Conor Dooley <Conor.Dooley@...rochip.com>
> Cc: Mark Rutland <mark.rutland@....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
>