From: Mark Rutland <mark.rutland@arm.com>
To: guoren@kernel.org
Cc: arnd@arndb.de, palmer@rivosinc.com, tglx@linutronix.de,
peterz@infradead.org, luto@kernel.org,
conor.dooley@microchip.com, heiko@sntech.de, jszhang@kernel.org,
lazyparser@gmail.com, falcon@tinylab.org, chenhuacai@kernel.org,
apatel@ventanamicro.com, atishp@atishpatra.org,
palmer@dabbelt.com, paul.walmsley@sifive.com,
zouyipeng@huawei.com, bigeasy@linutronix.de,
David.Laight@aculab.com, chenzhongjin@huawei.com,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org, Dao Lu <daolu@rivosinc.com>,
Xianting Tian <xianting.tian@linux.alibaba.com>
Subject: Re: [PATCH V6 09/11] riscv: Add support for STACKLEAK gcc plugin
Date: Mon, 3 Oct 2022 12:34:45 +0100 [thread overview]
Message-ID: <YzrI1QFMpHnhvDnI@FVFF77S0Q05N> (raw)
In-Reply-To: <20221002012451.2351127-10-guoren@kernel.org>
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
>
next prev parent reply other threads:[~2022-10-03 11:35 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-02 1:24 [PATCH V6 00/11] riscv: Add GENERIC_ENTRY support and related features guoren
2022-10-02 1:24 ` [PATCH V6 01/11] riscv: elf_kexec: Fixup compile warning guoren
2022-10-25 1:20 ` liaochang (A)
2022-10-25 2:36 ` Guo Ren
2022-10-02 1:24 ` [PATCH V6 02/11] riscv: compat_syscall_table: " guoren
2022-10-02 1:24 ` [PATCH V6 03/11] riscv: ptrace: Remove duplicate operation guoren
2022-10-02 1:24 ` [PATCH V6 04/11] compiler_types.h: Add __noinstr_section() for noinstr guoren
2022-10-03 11:38 ` Mark Rutland
2022-10-08 1:54 ` Guo Ren
2022-10-20 9:15 ` Mark Rutland
2022-10-20 12:29 ` Guo Ren
2022-10-24 11:56 ` Mark Rutland
2022-10-24 12:06 ` Peter Zijlstra
2022-10-24 12:14 ` Mark Rutland
2022-10-25 2:51 ` Guo Ren
2022-10-25 9:47 ` Mark Rutland
2022-10-02 1:24 ` [PATCH V6 05/11] riscv: traps: Add noinstr to prevent instrumentation inserted guoren
2022-10-03 11:40 ` Mark Rutland
2022-10-08 2:16 ` Guo Ren
2022-10-02 1:24 ` [PATCH V6 06/11] riscv: convert to generic entry guoren
2022-10-02 1:24 ` [PATCH V6 07/11] riscv: Support HAVE_IRQ_EXIT_ON_IRQ_STACK guoren
2022-10-02 1:24 ` [PATCH V6 08/11] riscv: Support HAVE_SOFTIRQ_ON_OWN_STACK guoren
2022-10-02 1:24 ` [PATCH V6 09/11] riscv: Add support for STACKLEAK gcc plugin guoren
2022-10-03 11:34 ` Mark Rutland [this message]
2022-10-08 0:16 ` Guo Ren
2022-10-08 3:26 ` Guo Ren
2022-10-08 3:44 ` Guo Ren
2022-10-02 1:24 ` [PATCH V6 10/11] riscv: Add config of thread stack size guoren
2022-10-02 1:24 ` [PATCH V6 11/11] riscv: remove extra level wrappers of trace_hardirqs_{on,off} guoren
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=YzrI1QFMpHnhvDnI@FVFF77S0Q05N \
--to=mark.rutland@arm.com \
--cc=David.Laight@aculab.com \
--cc=apatel@ventanamicro.com \
--cc=arnd@arndb.de \
--cc=atishp@atishpatra.org \
--cc=bigeasy@linutronix.de \
--cc=chenhuacai@kernel.org \
--cc=chenzhongjin@huawei.com \
--cc=conor.dooley@microchip.com \
--cc=daolu@rivosinc.com \
--cc=falcon@tinylab.org \
--cc=guoren@kernel.org \
--cc=heiko@sntech.de \
--cc=jszhang@kernel.org \
--cc=lazyparser@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=luto@kernel.org \
--cc=palmer@dabbelt.com \
--cc=palmer@rivosinc.com \
--cc=paul.walmsley@sifive.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=xianting.tian@linux.alibaba.com \
--cc=zouyipeng@huawei.com \
/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