Message ID | 20220903162328.1952477-1-guoren@kernel.org (mailing list archive) |
---|---|
Headers | show |
Series | arch: Cleanup ptrace_disable | expand |
On 03/09/2022 17:23, guoren@kernel.org wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > From: Xianting Tian <xianting.tian@linux.alibaba.com> > > This adds support for the STACKLEAK gcc plugin to RISC-V and disables > the plugin in EFI stub code, which is out of scope for the protection. > > For the benefits of STACKLEAK feature, please check the commit > afaef01c0015 ("x86/entry: Add STACKLEAK erasing the kernel stack at the end of syscalls") > > Performance impact (tested on qemu env with 1 riscv64 hart, 1GB mem) > hackbench -s 512 -l 200 -g 15 -f 25 -P > 2.0% slowdown > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> What changed since Xianting posted it himself a week ago: https://lore.kernel.org/linux-riscv/20220828135407.3897717-1-xianting.tian@linux.alibaba.com/ There's an older patch from Du Lao adding STACKLEAK too: https://lore.kernel.org/linux-riscv/20220615213834.3116135-1-daolu@rivosinc.com/ But since there's been no activity there since June... > --- > arch/riscv/Kconfig | 1 + > arch/riscv/include/asm/processor.h | 4 ++++ > arch/riscv/kernel/entry.S | 3 +++ > drivers/firmware/efi/libstub/Makefile | 2 +- > 4 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index ed66c31e4655..61fd0dad4463 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -85,6 +85,7 @@ config RISCV > select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE > select HAVE_ARCH_THREAD_STRUCT_WHITELIST > select HAVE_ARCH_VMAP_STACK if MMU && 64BIT > + select HAVE_ARCH_STACKLEAK > select HAVE_ASM_MODVERSIONS > select HAVE_CONTEXT_TRACKING_USER > select HAVE_DEBUG_KMEMLEAK > 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.17.1 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
Hi all, How about the generic_entry version: https://lore.kernel.org/lkml/20220907014809.919979-1-guoren@kernel.org/ On Wed, Sep 7, 2022 at 1:35 AM <Conor.Dooley@microchip.com> wrote: > > On 03/09/2022 17:23, guoren@kernel.org wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > > > From: Xianting Tian <xianting.tian@linux.alibaba.com> > > > > This adds support for the STACKLEAK gcc plugin to RISC-V and disables > > the plugin in EFI stub code, which is out of scope for the protection. > > > > For the benefits of STACKLEAK feature, please check the commit > > afaef01c0015 ("x86/entry: Add STACKLEAK erasing the kernel stack at the end of syscalls") > > > > Performance impact (tested on qemu env with 1 riscv64 hart, 1GB mem) > > hackbench -s 512 -l 200 -g 15 -f 25 -P > > 2.0% slowdown > > > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> > > What changed since Xianting posted it himself a week ago: > https://lore.kernel.org/linux-riscv/20220828135407.3897717-1-xianting.tian@linux.alibaba.com/ > > There's an older patch from Du Lao adding STACKLEAK too: > https://lore.kernel.org/linux-riscv/20220615213834.3116135-1-daolu@rivosinc.com/ > > But since there's been no activity there since June... > > > --- > > arch/riscv/Kconfig | 1 + > > arch/riscv/include/asm/processor.h | 4 ++++ > > arch/riscv/kernel/entry.S | 3 +++ > > drivers/firmware/efi/libstub/Makefile | 2 +- > > 4 files changed, 9 insertions(+), 1 deletion(-) > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > > index ed66c31e4655..61fd0dad4463 100644 > > --- a/arch/riscv/Kconfig > > +++ b/arch/riscv/Kconfig > > @@ -85,6 +85,7 @@ config RISCV > > select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE > > select HAVE_ARCH_THREAD_STRUCT_WHITELIST > > select HAVE_ARCH_VMAP_STACK if MMU && 64BIT > > + select HAVE_ARCH_STACKLEAK > > select HAVE_ASM_MODVERSIONS > > select HAVE_CONTEXT_TRACKING_USER > > select HAVE_DEBUG_KMEMLEAK > > 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.17.1 > > > > > > _______________________________________________ > > linux-riscv mailing list > > linux-riscv@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-riscv >
On Tue, 06 Sep 2022 10:35:10 PDT (-0700), Conor.Dooley@microchip.com wrote: > On 03/09/2022 17:23, guoren@kernel.org wrote: >> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >> >> From: Xianting Tian <xianting.tian@linux.alibaba.com> >> >> This adds support for the STACKLEAK gcc plugin to RISC-V and disables >> the plugin in EFI stub code, which is out of scope for the protection. >> >> For the benefits of STACKLEAK feature, please check the commit >> afaef01c0015 ("x86/entry: Add STACKLEAK erasing the kernel stack at the end of syscalls") >> >> Performance impact (tested on qemu env with 1 riscv64 hart, 1GB mem) >> hackbench -s 512 -l 200 -g 15 -f 25 -P >> 2.0% slowdown >> >> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> > > What changed since Xianting posted it himself a week ago: > https://lore.kernel.org/linux-riscv/20220828135407.3897717-1-xianting.tian@linux.alibaba.com/ > > There's an older patch from Du Lao adding STACKLEAK too: > https://lore.kernel.org/linux-riscv/20220615213834.3116135-1-daolu@rivosinc.com/ > > But since there's been no activity there since June... Looks like the only issues were some commit log wording stuff, and that there's a test suite that should be run. It's not clear from the commits that anyone has done that, I'm fine with the patch if it passes the tests but don't really know how to run them. Has anyone run the tests? > >> --- >> arch/riscv/Kconfig | 1 + >> arch/riscv/include/asm/processor.h | 4 ++++ >> arch/riscv/kernel/entry.S | 3 +++ >> drivers/firmware/efi/libstub/Makefile | 2 +- >> 4 files changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig >> index ed66c31e4655..61fd0dad4463 100644 >> --- a/arch/riscv/Kconfig >> +++ b/arch/riscv/Kconfig >> @@ -85,6 +85,7 @@ config RISCV >> select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE >> select HAVE_ARCH_THREAD_STRUCT_WHITELIST >> select HAVE_ARCH_VMAP_STACK if MMU && 64BIT >> + select HAVE_ARCH_STACKLEAK >> select HAVE_ASM_MODVERSIONS >> select HAVE_CONTEXT_TRACKING_USER >> select HAVE_DEBUG_KMEMLEAK >> 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.17.1 >> >> >> _______________________________________________ >> linux-riscv mailing list >> linux-riscv@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-riscv >
On Thu, Oct 06, 2022 at 07:31:01PM -0700, Palmer Dabbelt wrote: > On Tue, 06 Sep 2022 10:35:10 PDT (-0700), Conor.Dooley@microchip.com wrote: > > On 03/09/2022 17:23, guoren@kernel.org wrote: > > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > > > > > From: Xianting Tian <xianting.tian@linux.alibaba.com> > > > > > > This adds support for the STACKLEAK gcc plugin to RISC-V and disables > > > the plugin in EFI stub code, which is out of scope for the protection. > > > > > > For the benefits of STACKLEAK feature, please check the commit > > > afaef01c0015 ("x86/entry: Add STACKLEAK erasing the kernel stack at the end of syscalls") > > > > > > Performance impact (tested on qemu env with 1 riscv64 hart, 1GB mem) > > > hackbench -s 512 -l 200 -g 15 -f 25 -P > > > 2.0% slowdown > > > > > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> > > > > What changed since Xianting posted it himself a week ago: > > https://lore.kernel.org/linux-riscv/20220828135407.3897717-1-xianting.tian@linux.alibaba.com/ > > > > There's an older patch from Du Lao adding STACKLEAK too: > > https://lore.kernel.org/linux-riscv/20220615213834.3116135-1-daolu@rivosinc.com/ > > > > But since there's been no activity there since June... > > Looks like the only issues were some commit log wording stuff, and that > there's a test suite that should be run. It's not clear from the commits > that anyone has done that, I'm fine with the patch if it passes the tests > but don't really know how to run them. Enable CONFIG_LKDTM, and do: echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT Example GOOD/BAD output below, taken from: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/misc/lkdtm/stackleak.c?id=72b61896f2b47fa4b98e86184bc0e6ddbd1a8db1 GOOD result on x86_64: | # echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT | lkdtm: Performing direct entry STACKLEAK_ERASING | lkdtm: stackleak stack usage: | high offset: 168 bytes | current: 336 bytes | lowest: 656 bytes | tracked: 656 bytes | untracked: 400 bytes | poisoned: 15152 bytes | low offset: 8 bytes | lkdtm: OK: the rest of the thread stack is properly erased GOOD result on arm64: | # echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT | lkdtm: Performing direct entry STACKLEAK_ERASING | lkdtm: stackleak stack usage: | high offset: 336 bytes | current: 656 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 BAD result on arm64: | # echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT | lkdtm: Performing direct entry STACKLEAK_ERASING | lkdtm: FAIL: non-poison value 24 bytes below poison boundary: 0x0 | lkdtm: FAIL: non-poison value 32 bytes below poison boundary: 0xffff8000083dbc00 ... | lkdtm: FAIL: non-poison value 1912 bytes below poison boundary: 0x78b4b9999e8cb15 | lkdtm: FAIL: non-poison value 1920 bytes below poison boundary: 0xffff8000083db400 | lkdtm: stackleak stack usage: | high offset: 336 bytes | current: 688 bytes | lowest: 1232 bytes | tracked: 576 bytes | untracked: 288 bytes | poisoned: 15176 bytes | low offset: 8 bytes | lkdtm: FAIL: the thread stack is NOT properly erased! | lkdtm: Unexpected! This kernel (5.18.0-rc1-00013-g1f7b1f1e29e0-dirty aarch64) was built with CONFIG_GCC_PLUGIN_STACKLEAK=y Mark.
On Fri, Oct 7, 2022 at 10:31 AM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > On Tue, 06 Sep 2022 10:35:10 PDT (-0700), Conor.Dooley@microchip.com wrote: > > On 03/09/2022 17:23, guoren@kernel.org wrote: > >> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > >> > >> From: Xianting Tian <xianting.tian@linux.alibaba.com> > >> > >> This adds support for the STACKLEAK gcc plugin to RISC-V and disables > >> the plugin in EFI stub code, which is out of scope for the protection. > >> > >> For the benefits of STACKLEAK feature, please check the commit > >> afaef01c0015 ("x86/entry: Add STACKLEAK erasing the kernel stack at the end of syscalls") > >> > >> Performance impact (tested on qemu env with 1 riscv64 hart, 1GB mem) > >> hackbench -s 512 -l 200 -g 15 -f 25 -P > >> 2.0% slowdown > >> > >> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> > > > > What changed since Xianting posted it himself a week ago: > > https://lore.kernel.org/linux-riscv/20220828135407.3897717-1-xianting.tian@linux.alibaba.com/ > > > > There's an older patch from Du Lao adding STACKLEAK too: > > https://lore.kernel.org/linux-riscv/20220615213834.3116135-1-daolu@rivosinc.com/ > > > > But since there's been no activity there since June... > > Looks like the only issues were some commit log wording stuff, and that > there's a test suite that should be run. It's not clear from the > commits that anyone has done that, I'm fine with the patch if it passes > the tests but don't really know how to run them. > > Has anyone run the tests? I'm trying to do that with genric_entry. https://lore.kernel.org/linux-riscv/20220615213834.3116135-1-daolu@rivosinc.com/ Mark Rutland has found an issue, and I'm solving it. > > > > >> --- > >> arch/riscv/Kconfig | 1 + > >> arch/riscv/include/asm/processor.h | 4 ++++ > >> arch/riscv/kernel/entry.S | 3 +++ > >> drivers/firmware/efi/libstub/Makefile | 2 +- > >> 4 files changed, 9 insertions(+), 1 deletion(-) > >> > >> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > >> index ed66c31e4655..61fd0dad4463 100644 > >> --- a/arch/riscv/Kconfig > >> +++ b/arch/riscv/Kconfig > >> @@ -85,6 +85,7 @@ config RISCV > >> select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE > >> select HAVE_ARCH_THREAD_STRUCT_WHITELIST > >> select HAVE_ARCH_VMAP_STACK if MMU && 64BIT > >> + select HAVE_ARCH_STACKLEAK > >> select HAVE_ASM_MODVERSIONS > >> select HAVE_CONTEXT_TRACKING_USER > >> select HAVE_DEBUG_KMEMLEAK > >> 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.17.1 > >> > >> > >> _______________________________________________ > >> linux-riscv mailing list > >> linux-riscv@lists.infradead.org > >> http://lists.infradead.org/mailman/listinfo/linux-riscv > >
From: Guo Ren <guoren@linux.alibaba.com> This series cleanup ptrace_disable() in arch/*. Some architectures are duplicate clearing SYSCALL TRACE. Changes in V2: - Rebase on linux-6.0-rc3 - Add Reviewed-by tags. Guo Ren (3): riscv: ptrace: Remove duplicate operation openrisc: ptrace: Remove duplicate operation arch: ptrace: Cleanup ptrace_disable arch/arc/kernel/ptrace.c | 4 ---- arch/arm/kernel/ptrace.c | 8 -------- arch/microblaze/kernel/ptrace.c | 5 ----- arch/nios2/kernel/ptrace.c | 5 ----- arch/openrisc/kernel/ptrace.c | 1 - arch/riscv/kernel/ptrace.c | 5 ----- arch/sparc/kernel/ptrace_32.c | 10 ---------- arch/sparc/kernel/ptrace_64.c | 10 ---------- kernel/ptrace.c | 8 ++++++++ 9 files changed, 8 insertions(+), 48 deletions(-)