All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laura Abbott <labbott@redhat.com>
To: Kees Cook <keescook@chromium.org>
Cc: Alexander Popov <alex.popov@linux.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Kernel Hardening <kernel-hardening@lists.openwall.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] arm64: Clear the stack
Date: Wed, 2 May 2018 16:07:01 -0700	[thread overview]
Message-ID: <4b7e94c1-79c9-0380-25c6-762762ed595f@redhat.com> (raw)
In-Reply-To: <CAGXu5jK1_--omGSqz03sfB8twQVzy9ZQR9Xzi-uxseekp+r1jQ@mail.gmail.com>

On 05/02/2018 02:31 PM, Kees Cook wrote:
> On Wed, May 2, 2018 at 1:33 PM, Laura Abbott <labbott@redhat.com> wrote:
>>
>> Implementation of stackleak based heavily on the x86 version
> 
> Awesome! Notes below for both you and Alexander, since I think we can
> create a common code base instead of having near-duplicates in the
> arch/ trees...
> 
>>
>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>> ---
>> Now written in C instead of a bunch of assembly.
>> ---
>>   arch/arm64/Kconfig                    |  1 +
>>   arch/arm64/include/asm/processor.h    |  6 ++++
>>   arch/arm64/kernel/Makefile            |  3 ++
>>   arch/arm64/kernel/entry.S             |  6 ++++
>>   arch/arm64/kernel/erase.c             | 55 +++++++++++++++++++++++++++++++++++
>>   arch/arm64/kernel/process.c           | 16 ++++++++++
>>   drivers/firmware/efi/libstub/Makefile |  3 +-
>>   scripts/Makefile.gcc-plugins          |  5 +++-
>>   8 files changed, 93 insertions(+), 2 deletions(-)
>>   create mode 100644 arch/arm64/kernel/erase.c
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index eb2cf4938f6d..b0221db95dc9 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -92,6 +92,7 @@ config ARM64
>>          select HAVE_ARCH_MMAP_RND_BITS
>>          select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
>>          select HAVE_ARCH_SECCOMP_FILTER
>> +       select HAVE_ARCH_STACKLEAK
>>          select HAVE_ARCH_THREAD_STRUCT_WHITELIST
>>          select HAVE_ARCH_TRACEHOOK
>>          select HAVE_ARCH_TRANSPARENT_HUGEPAGE
>> diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
>> index 767598932549..d31ab80ff647 100644
>> --- a/arch/arm64/include/asm/processor.h
>> +++ b/arch/arm64/include/asm/processor.h
>> @@ -124,6 +124,12 @@ struct thread_struct {
>>          unsigned long           fault_address;  /* fault info */
>>          unsigned long           fault_code;     /* ESR_EL1 value */
>>          struct debug_info       debug;          /* debugging */
>> +#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>> +       unsigned long           lowest_stack;
>> +#ifdef CONFIG_STACKLEAK_METRICS
>> +       unsigned long           prev_lowest_stack;
>> +#endif
>> +#endif
> 
> I wonder if x86 and arm64 could include a common struct here that was
> empty when the plugin is disabled... it would keep the ifdefs in one
> place. Maybe include/linux/stackleak.h could be:
> 
> ---start---
> /* Poison value points to the unused hole in the virtual memory map */
> #define STACKLEAK_POISON -0xBEEF
> #define STACKLEAK_POISON_CHECK_DEPTH 128
> 
> struct stackleak {
> #ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>         unsigned long           lowest;
> #ifdef CONFIG_STACKLEAK_METRICS
>         unsigned long           prev_lowest;
> #endif
> #endif
> };
> 

Is this well defined across all compilers if the plugin is off?
This seems to compile with gcc at least but 0 sized structs
make me a little uneasy.

> asmlinkage void erase_kstack(void);
> ---eof---
> 
> and arch/*/include/asm/processor.h could do:
> 
> @@ -124,6 +124,12 @@ struct thread_struct {
>          unsigned long           fault_address;  /* fault info */
>          unsigned long           fault_code;     /* ESR_EL1 value */
>          struct debug_info       debug;          /* debugging */
> +       struct stackleak         stackleak;
> 
> and arch/x86/entry/erase.c could move to maybe kernel/stackleak.c?
> (Oh, I notice this needs an SPDX line too.)
> 
>>   static inline void arch_thread_struct_whitelist(unsigned long *offset,
>> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
>> index bf825f38d206..0ceea613c65b 100644
>> --- a/arch/arm64/kernel/Makefile
>> +++ b/arch/arm64/kernel/Makefile
>> @@ -55,6 +55,9 @@ arm64-reloc-test-y := reloc_test_core.o reloc_test_syms.o
>>   arm64-obj-$(CONFIG_CRASH_DUMP)         += crash_dump.o
>>   arm64-obj-$(CONFIG_ARM_SDE_INTERFACE)  += sdei.o
>>
>> +arm64-obj-$(CONFIG_GCC_PLUGIN_STACKLEAK) += erase.o
>> +KASAN_SANITIZE_erase.o := n
>> +
>>   obj-y                                  += $(arm64-obj-y) vdso/ probes/
>>   obj-m                                  += $(arm64-obj-m)
>>   head-y                                 := head.o
>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>> index ec2ee720e33e..3144f1ebdc18 100644
>> --- a/arch/arm64/kernel/entry.S
>> +++ b/arch/arm64/kernel/entry.S
>> @@ -401,6 +401,11 @@ tsk        .req    x28             // current thread_info
>>
>>          .text
>>
>> +       .macro  ERASE_KSTACK
>> +#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>> +       bl      erase_kstack
>> +#endif
>> +       .endm
>>   /*
>>    * Exception vectors.
>>    */
>> @@ -906,6 +911,7 @@ ret_to_user:
>>          cbnz    x2, work_pending
>>   finish_ret_to_user:
>>          enable_step_tsk x1, x2
>> +       ERASE_KSTACK
>>          kernel_exit 0
>>   ENDPROC(ret_to_user)
> 
> Nice. All of the return paths end up here (I went looking for
> ret_from_fork's path). :)
> 
>>
>> diff --git a/arch/arm64/kernel/erase.c b/arch/arm64/kernel/erase.c
>> new file mode 100644
>> index 000000000000..b8b5648d893b
>> --- /dev/null
>> +++ b/arch/arm64/kernel/erase.c
>> @@ -0,0 +1,55 @@
>> +#include <linux/bug.h>
>> +#include <linux/sched.h>
>> +#include <asm/current.h>
>> +#include <asm/linkage.h>
>> +#include <asm/processor.h>
>> +
>> +asmlinkage void erase_kstack(void)
>> +{
>> +       unsigned long p = current->thread.lowest_stack;
>> +       unsigned long boundary = p & ~(THREAD_SIZE - 1);
>> +       unsigned long poison = 0;
>> +       const unsigned long check_depth = STACKLEAK_POISON_CHECK_DEPTH /
>> +                                                       sizeof(unsigned long);
>> +
>> +       /*
>> +        * Let's search for the poison value in the stack.
>> +        * Start from the lowest_stack and go to the bottom.
>> +        */
>> +       while (p > boundary && poison <= check_depth) {
>> +               if (*(unsigned long *)p == STACKLEAK_POISON)
>> +                       poison++;
>> +               else
>> +                       poison = 0;
>> +
>> +               p -= sizeof(unsigned long);
>> +       }
>> +
>> +       /*
>> +        * One long int at the bottom of the thread stack is reserved and
>> +        * should not be poisoned (see CONFIG_SCHED_STACK_END_CHECK).
>> +        */
>> +       if (p == boundary)
>> +               p += sizeof(unsigned long);
>> +
>> +#ifdef CONFIG_STACKLEAK_METRICS
>> +       current->thread.prev_lowest_stack = p;
>> +#endif
>> +
>> +       /*
>> +        * So let's write the poison value to the kernel stack.
>> +        * Start from the address in p and move up till the new boundary.
>> +        */
>> +       boundary = current_stack_pointer;
> 
> This is the only difference between x86 and arm64 in this code. What
> do you think about implementing on_thread_stack() to match x86:
> 
>          if (on_thread_stack())
>                  boundary = current_stack_pointer;
>          else
>                  boundary = current_top_of_stack();
> 
> then we could make this common code too instead of having two copies in arch/?
> 

The issue isn't on_thread_stack, it's current_top_of_stack which isn't
defined on arm64. I agree it would be good if the code would be common
but I'm not sure how much we want to start trying to force APIs.

>> +       BUG_ON(boundary - p >= THREAD_SIZE);
>> +
>> +       while (p < boundary) {
>> +               *(unsigned long *)p = STACKLEAK_POISON;
>> +               p += sizeof(unsigned long);
>> +       }
>> +
>> +       /* Reset the lowest_stack value for the next syscall */
>> +       current->thread.lowest_stack = current_stack_pointer;
>> +}
>> +
>> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
>> index f08a2ed9db0d..156fa0a0da19 100644
>> --- a/arch/arm64/kernel/process.c
>> +++ b/arch/arm64/kernel/process.c
>> @@ -364,6 +364,9 @@ int copy_thread(unsigned long clone_flags, unsigned long stack_start,
>>          p->thread.cpu_context.pc = (unsigned long)ret_from_fork;
>>          p->thread.cpu_context.sp = (unsigned long)childregs;
>>
>> +#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>> +       p->thread.lowest_stack = (unsigned long)task_stack_page(p);
>> +#endif
>>          ptrace_hw_copy_thread(p);
>>
>>          return 0;
>> @@ -493,3 +496,16 @@ void arch_setup_new_exec(void)
>>   {
>>          current->mm->context.flags = is_compat_task() ? MMCF_AARCH32 : 0;
>>   }
>> +
>> +#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>> +void __used check_alloca(unsigned long size)
>> +{
>> +       unsigned long sp, stack_left;
>> +
>> +       sp = current_stack_pointer;
>> +
>> +       stack_left = sp & (THREAD_SIZE - 1);
>> +       BUG_ON(stack_left < 256 || size >= stack_left - 256);
>> +}
>> +EXPORT_SYMBOL(check_alloca);
> 
> This is pretty different from x86. Is this just an artifact of ORC, or
> something else?
> 

This was based on the earlier version of x86. I'll confess to
not seeing how the current x86 version ended up with get_stack_info
but I suspect it's either related to ORC unwinding or it's best
practice.

>> +#endif
>> diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
>> index a34e9290a699..25dd2a14560d 100644
>> --- a/drivers/firmware/efi/libstub/Makefile
>> +++ b/drivers/firmware/efi/libstub/Makefile
>> @@ -20,7 +20,8 @@ cflags-$(CONFIG_EFI_ARMSTUB)  += -I$(srctree)/scripts/dtc/libfdt
>>   KBUILD_CFLAGS                  := $(cflags-y) -DDISABLE_BRANCH_PROFILING \
>>                                     -D__NO_FORTIFY \
>>                                     $(call cc-option,-ffreestanding) \
>> -                                  $(call cc-option,-fno-stack-protector)
>> +                                  $(call cc-option,-fno-stack-protector) \
>> +                                  $(DISABLE_STACKLEAK_PLUGIN)
>>
>>   GCOV_PROFILE                   := n
>>   KASAN_SANITIZE                 := n
>> diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
>> index 8d6070fc538f..6cc0e35d3324 100644
>> --- a/scripts/Makefile.gcc-plugins
>> +++ b/scripts/Makefile.gcc-plugins
>> @@ -37,11 +37,14 @@ ifdef CONFIG_GCC_PLUGINS
>>
>>     gcc-plugin-$(CONFIG_GCC_PLUGIN_STACKLEAK)    += stackleak_plugin.so
>>     gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STACKLEAK)     += -DSTACKLEAK_PLUGIN -fplugin-arg-stackleak_plugin-track-min-size=$(CONFIG_STACKLEAK_TRACK_MIN_SIZE)
>> +  ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>> +    DISABLE_STACKLEAK_PLUGIN           += -fplugin-arg-stackleak_plugin-disable
>> +  endif
>>
>>     GCC_PLUGINS_CFLAGS := $(strip $(addprefix -fplugin=$(objtree)/scripts/gcc-plugins/, $(gcc-plugin-y)) $(gcc-plugin-cflags-y))
>>
>>     export PLUGINCC GCC_PLUGINS_CFLAGS GCC_PLUGIN GCC_PLUGIN_SUBDIR
>> -  export SANCOV_PLUGIN DISABLE_LATENT_ENTROPY_PLUGIN
>> +  export SANCOV_PLUGIN DISABLE_LATENT_ENTROPY_PLUGIN DISABLE_STACKLEAK_PLUGIN
>>
>>     ifneq ($(PLUGINCC),)
>>       # SANCOV_PLUGIN can be only in CFLAGS_KCOV because avoid duplication.
>> --
>> 2.14.3
>>
> 
> -Kees
> 

Thanks,
Laura

WARNING: multiple messages have this Message-ID (diff)
From: labbott@redhat.com (Laura Abbott)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] arm64: Clear the stack
Date: Wed, 2 May 2018 16:07:01 -0700	[thread overview]
Message-ID: <4b7e94c1-79c9-0380-25c6-762762ed595f@redhat.com> (raw)
In-Reply-To: <CAGXu5jK1_--omGSqz03sfB8twQVzy9ZQR9Xzi-uxseekp+r1jQ@mail.gmail.com>

On 05/02/2018 02:31 PM, Kees Cook wrote:
> On Wed, May 2, 2018 at 1:33 PM, Laura Abbott <labbott@redhat.com> wrote:
>>
>> Implementation of stackleak based heavily on the x86 version
> 
> Awesome! Notes below for both you and Alexander, since I think we can
> create a common code base instead of having near-duplicates in the
> arch/ trees...
> 
>>
>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>> ---
>> Now written in C instead of a bunch of assembly.
>> ---
>>   arch/arm64/Kconfig                    |  1 +
>>   arch/arm64/include/asm/processor.h    |  6 ++++
>>   arch/arm64/kernel/Makefile            |  3 ++
>>   arch/arm64/kernel/entry.S             |  6 ++++
>>   arch/arm64/kernel/erase.c             | 55 +++++++++++++++++++++++++++++++++++
>>   arch/arm64/kernel/process.c           | 16 ++++++++++
>>   drivers/firmware/efi/libstub/Makefile |  3 +-
>>   scripts/Makefile.gcc-plugins          |  5 +++-
>>   8 files changed, 93 insertions(+), 2 deletions(-)
>>   create mode 100644 arch/arm64/kernel/erase.c
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index eb2cf4938f6d..b0221db95dc9 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -92,6 +92,7 @@ config ARM64
>>          select HAVE_ARCH_MMAP_RND_BITS
>>          select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
>>          select HAVE_ARCH_SECCOMP_FILTER
>> +       select HAVE_ARCH_STACKLEAK
>>          select HAVE_ARCH_THREAD_STRUCT_WHITELIST
>>          select HAVE_ARCH_TRACEHOOK
>>          select HAVE_ARCH_TRANSPARENT_HUGEPAGE
>> diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
>> index 767598932549..d31ab80ff647 100644
>> --- a/arch/arm64/include/asm/processor.h
>> +++ b/arch/arm64/include/asm/processor.h
>> @@ -124,6 +124,12 @@ struct thread_struct {
>>          unsigned long           fault_address;  /* fault info */
>>          unsigned long           fault_code;     /* ESR_EL1 value */
>>          struct debug_info       debug;          /* debugging */
>> +#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>> +       unsigned long           lowest_stack;
>> +#ifdef CONFIG_STACKLEAK_METRICS
>> +       unsigned long           prev_lowest_stack;
>> +#endif
>> +#endif
> 
> I wonder if x86 and arm64 could include a common struct here that was
> empty when the plugin is disabled... it would keep the ifdefs in one
> place. Maybe include/linux/stackleak.h could be:
> 
> ---start---
> /* Poison value points to the unused hole in the virtual memory map */
> #define STACKLEAK_POISON -0xBEEF
> #define STACKLEAK_POISON_CHECK_DEPTH 128
> 
> struct stackleak {
> #ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>         unsigned long           lowest;
> #ifdef CONFIG_STACKLEAK_METRICS
>         unsigned long           prev_lowest;
> #endif
> #endif
> };
> 

Is this well defined across all compilers if the plugin is off?
This seems to compile with gcc at least but 0 sized structs
make me a little uneasy.

> asmlinkage void erase_kstack(void);
> ---eof---
> 
> and arch/*/include/asm/processor.h could do:
> 
> @@ -124,6 +124,12 @@ struct thread_struct {
>          unsigned long           fault_address;  /* fault info */
>          unsigned long           fault_code;     /* ESR_EL1 value */
>          struct debug_info       debug;          /* debugging */
> +       struct stackleak         stackleak;
> 
> and arch/x86/entry/erase.c could move to maybe kernel/stackleak.c?
> (Oh, I notice this needs an SPDX line too.)
> 
>>   static inline void arch_thread_struct_whitelist(unsigned long *offset,
>> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
>> index bf825f38d206..0ceea613c65b 100644
>> --- a/arch/arm64/kernel/Makefile
>> +++ b/arch/arm64/kernel/Makefile
>> @@ -55,6 +55,9 @@ arm64-reloc-test-y := reloc_test_core.o reloc_test_syms.o
>>   arm64-obj-$(CONFIG_CRASH_DUMP)         += crash_dump.o
>>   arm64-obj-$(CONFIG_ARM_SDE_INTERFACE)  += sdei.o
>>
>> +arm64-obj-$(CONFIG_GCC_PLUGIN_STACKLEAK) += erase.o
>> +KASAN_SANITIZE_erase.o := n
>> +
>>   obj-y                                  += $(arm64-obj-y) vdso/ probes/
>>   obj-m                                  += $(arm64-obj-m)
>>   head-y                                 := head.o
>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>> index ec2ee720e33e..3144f1ebdc18 100644
>> --- a/arch/arm64/kernel/entry.S
>> +++ b/arch/arm64/kernel/entry.S
>> @@ -401,6 +401,11 @@ tsk        .req    x28             // current thread_info
>>
>>          .text
>>
>> +       .macro  ERASE_KSTACK
>> +#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>> +       bl      erase_kstack
>> +#endif
>> +       .endm
>>   /*
>>    * Exception vectors.
>>    */
>> @@ -906,6 +911,7 @@ ret_to_user:
>>          cbnz    x2, work_pending
>>   finish_ret_to_user:
>>          enable_step_tsk x1, x2
>> +       ERASE_KSTACK
>>          kernel_exit 0
>>   ENDPROC(ret_to_user)
> 
> Nice. All of the return paths end up here (I went looking for
> ret_from_fork's path). :)
> 
>>
>> diff --git a/arch/arm64/kernel/erase.c b/arch/arm64/kernel/erase.c
>> new file mode 100644
>> index 000000000000..b8b5648d893b
>> --- /dev/null
>> +++ b/arch/arm64/kernel/erase.c
>> @@ -0,0 +1,55 @@
>> +#include <linux/bug.h>
>> +#include <linux/sched.h>
>> +#include <asm/current.h>
>> +#include <asm/linkage.h>
>> +#include <asm/processor.h>
>> +
>> +asmlinkage void erase_kstack(void)
>> +{
>> +       unsigned long p = current->thread.lowest_stack;
>> +       unsigned long boundary = p & ~(THREAD_SIZE - 1);
>> +       unsigned long poison = 0;
>> +       const unsigned long check_depth = STACKLEAK_POISON_CHECK_DEPTH /
>> +                                                       sizeof(unsigned long);
>> +
>> +       /*
>> +        * Let's search for the poison value in the stack.
>> +        * Start from the lowest_stack and go to the bottom.
>> +        */
>> +       while (p > boundary && poison <= check_depth) {
>> +               if (*(unsigned long *)p == STACKLEAK_POISON)
>> +                       poison++;
>> +               else
>> +                       poison = 0;
>> +
>> +               p -= sizeof(unsigned long);
>> +       }
>> +
>> +       /*
>> +        * One long int at the bottom of the thread stack is reserved and
>> +        * should not be poisoned (see CONFIG_SCHED_STACK_END_CHECK).
>> +        */
>> +       if (p == boundary)
>> +               p += sizeof(unsigned long);
>> +
>> +#ifdef CONFIG_STACKLEAK_METRICS
>> +       current->thread.prev_lowest_stack = p;
>> +#endif
>> +
>> +       /*
>> +        * So let's write the poison value to the kernel stack.
>> +        * Start from the address in p and move up till the new boundary.
>> +        */
>> +       boundary = current_stack_pointer;
> 
> This is the only difference between x86 and arm64 in this code. What
> do you think about implementing on_thread_stack() to match x86:
> 
>          if (on_thread_stack())
>                  boundary = current_stack_pointer;
>          else
>                  boundary = current_top_of_stack();
> 
> then we could make this common code too instead of having two copies in arch/?
> 

The issue isn't on_thread_stack, it's current_top_of_stack which isn't
defined on arm64. I agree it would be good if the code would be common
but I'm not sure how much we want to start trying to force APIs.

>> +       BUG_ON(boundary - p >= THREAD_SIZE);
>> +
>> +       while (p < boundary) {
>> +               *(unsigned long *)p = STACKLEAK_POISON;
>> +               p += sizeof(unsigned long);
>> +       }
>> +
>> +       /* Reset the lowest_stack value for the next syscall */
>> +       current->thread.lowest_stack = current_stack_pointer;
>> +}
>> +
>> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
>> index f08a2ed9db0d..156fa0a0da19 100644
>> --- a/arch/arm64/kernel/process.c
>> +++ b/arch/arm64/kernel/process.c
>> @@ -364,6 +364,9 @@ int copy_thread(unsigned long clone_flags, unsigned long stack_start,
>>          p->thread.cpu_context.pc = (unsigned long)ret_from_fork;
>>          p->thread.cpu_context.sp = (unsigned long)childregs;
>>
>> +#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>> +       p->thread.lowest_stack = (unsigned long)task_stack_page(p);
>> +#endif
>>          ptrace_hw_copy_thread(p);
>>
>>          return 0;
>> @@ -493,3 +496,16 @@ void arch_setup_new_exec(void)
>>   {
>>          current->mm->context.flags = is_compat_task() ? MMCF_AARCH32 : 0;
>>   }
>> +
>> +#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>> +void __used check_alloca(unsigned long size)
>> +{
>> +       unsigned long sp, stack_left;
>> +
>> +       sp = current_stack_pointer;
>> +
>> +       stack_left = sp & (THREAD_SIZE - 1);
>> +       BUG_ON(stack_left < 256 || size >= stack_left - 256);
>> +}
>> +EXPORT_SYMBOL(check_alloca);
> 
> This is pretty different from x86. Is this just an artifact of ORC, or
> something else?
> 

This was based on the earlier version of x86. I'll confess to
not seeing how the current x86 version ended up with get_stack_info
but I suspect it's either related to ORC unwinding or it's best
practice.

>> +#endif
>> diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
>> index a34e9290a699..25dd2a14560d 100644
>> --- a/drivers/firmware/efi/libstub/Makefile
>> +++ b/drivers/firmware/efi/libstub/Makefile
>> @@ -20,7 +20,8 @@ cflags-$(CONFIG_EFI_ARMSTUB)  += -I$(srctree)/scripts/dtc/libfdt
>>   KBUILD_CFLAGS                  := $(cflags-y) -DDISABLE_BRANCH_PROFILING \
>>                                     -D__NO_FORTIFY \
>>                                     $(call cc-option,-ffreestanding) \
>> -                                  $(call cc-option,-fno-stack-protector)
>> +                                  $(call cc-option,-fno-stack-protector) \
>> +                                  $(DISABLE_STACKLEAK_PLUGIN)
>>
>>   GCOV_PROFILE                   := n
>>   KASAN_SANITIZE                 := n
>> diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
>> index 8d6070fc538f..6cc0e35d3324 100644
>> --- a/scripts/Makefile.gcc-plugins
>> +++ b/scripts/Makefile.gcc-plugins
>> @@ -37,11 +37,14 @@ ifdef CONFIG_GCC_PLUGINS
>>
>>     gcc-plugin-$(CONFIG_GCC_PLUGIN_STACKLEAK)    += stackleak_plugin.so
>>     gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STACKLEAK)     += -DSTACKLEAK_PLUGIN -fplugin-arg-stackleak_plugin-track-min-size=$(CONFIG_STACKLEAK_TRACK_MIN_SIZE)
>> +  ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>> +    DISABLE_STACKLEAK_PLUGIN           += -fplugin-arg-stackleak_plugin-disable
>> +  endif
>>
>>     GCC_PLUGINS_CFLAGS := $(strip $(addprefix -fplugin=$(objtree)/scripts/gcc-plugins/, $(gcc-plugin-y)) $(gcc-plugin-cflags-y))
>>
>>     export PLUGINCC GCC_PLUGINS_CFLAGS GCC_PLUGIN GCC_PLUGIN_SUBDIR
>> -  export SANCOV_PLUGIN DISABLE_LATENT_ENTROPY_PLUGIN
>> +  export SANCOV_PLUGIN DISABLE_LATENT_ENTROPY_PLUGIN DISABLE_STACKLEAK_PLUGIN
>>
>>     ifneq ($(PLUGINCC),)
>>       # SANCOV_PLUGIN can be only in CFLAGS_KCOV because avoid duplication.
>> --
>> 2.14.3
>>
> 
> -Kees
> 

Thanks,
Laura

  reply	other threads:[~2018-05-02 23:07 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-06 14:22 [PATCH v11 0/6] Introduce the STACKLEAK feature and a test for it Alexander Popov
2018-04-06 14:22 ` [PATCH v11 1/6] gcc-plugins: Clean up the cgraph_create_edge* macros Alexander Popov
2018-04-06 14:22 ` [PATCH v11 2/6] x86/entry: Add STACKLEAK erasing the kernel stack at the end of syscalls Alexander Popov
2018-04-16 18:29   ` Kees Cook
2018-04-18 18:33     ` Laura Abbott
2018-04-18 18:50     ` Dave Hansen
2018-04-24  1:03       ` Kees Cook
2018-04-24  4:23   ` Dave Hansen
2018-04-30 23:48     ` Kees Cook
2018-05-02  8:42       ` Thomas Gleixner
2018-05-02 12:38         ` Kees Cook
2018-05-02 12:39           ` Thomas Gleixner
2018-05-02 12:51             ` Kees Cook
2018-05-02 21:02               ` Kees Cook
2018-05-06 10:04                 ` Thomas Gleixner
2018-04-06 14:22 ` [PATCH v11 3/6] gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack Alexander Popov
2018-04-06 14:22 ` [PATCH v11 4/6] lkdtm: Add a test for STACKLEAK Alexander Popov
2018-04-06 14:22 ` [PATCH v11 5/6] fs/proc: Show STACKLEAK metrics in the /proc file system Alexander Popov
2018-04-06 14:22 ` [PATCH v11 6/6] doc: self-protection: Add information about STACKLEAK feature Alexander Popov
2018-05-02 20:33 ` [PATCH 0/2] Stackleak for arm64 Laura Abbott
2018-05-02 20:33   ` Laura Abbott
2018-05-02 20:33   ` [PATCH 1/2] stackleak: Update " Laura Abbott
2018-05-02 20:33     ` Laura Abbott
2018-05-02 20:33   ` [PATCH 2/2] arm64: Clear the stack Laura Abbott
2018-05-02 20:33     ` Laura Abbott
2018-05-02 21:31     ` Kees Cook
2018-05-02 21:31       ` Kees Cook
2018-05-02 23:07       ` Laura Abbott [this message]
2018-05-02 23:07         ` Laura Abbott
2018-05-02 23:37         ` Kees Cook
2018-05-02 23:37           ` Kees Cook
2018-05-03 16:05         ` Alexander Popov
2018-05-03 16:05           ` Alexander Popov
2018-05-03 16:45           ` Kees Cook
2018-05-03 16:45             ` Kees Cook
2018-05-03  7:19     ` Mark Rutland
2018-05-03  7:19       ` Mark Rutland
2018-05-03 11:37       ` Ard Biesheuvel
2018-05-03 11:37         ` Ard Biesheuvel
2018-05-03 17:33       ` Alexander Popov
2018-05-03 17:33         ` Alexander Popov
2018-05-03 19:09         ` Laura Abbott
2018-05-03 19:09           ` Laura Abbott
2018-05-04  8:30           ` Alexander Popov
2018-05-04  8:30             ` Alexander Popov
2018-05-04 11:09         ` Mark Rutland
2018-05-04 11:09           ` Mark Rutland
2018-05-06  8:22           ` Alexander Popov
2018-05-06  8:22             ` Alexander Popov
2018-05-11 15:50             ` Alexander Popov
2018-05-11 15:50               ` Alexander Popov
2018-05-11 16:13               ` Mark Rutland
2018-05-11 16:13                 ` Mark Rutland
2018-05-13  8:40                 ` Alexander Popov
2018-05-13  8:40                   ` Alexander Popov
2018-05-14  5:15                   ` Mark Rutland
2018-05-14  5:15                     ` Mark Rutland
2018-05-14  9:35                     ` Alexander Popov
2018-05-14  9:35                       ` Alexander Popov
2018-05-14 10:06                       ` Mark Rutland
2018-05-14 10:06                         ` Mark Rutland
2018-05-14 13:53                         ` Alexander Popov
2018-05-14 13:53                           ` Alexander Popov
2018-05-14 14:07                           ` Mark Rutland
2018-05-14 14:07                             ` Mark Rutland
2018-05-03 19:00       ` Laura Abbott
2018-05-03 19:00         ` Laura Abbott
2018-05-04 11:16         ` Mark Rutland
2018-05-04 11:16           ` Mark Rutland
2018-05-14 18:55 ` [PATCH v11 0/6] Introduce the STACKLEAK feature and a test for it Laura Abbott
  -- strict thread matches above, loose matches on Subject: below --
2018-07-18 21:10 [PATCH 0/2] Stackleak for arm64 Laura Abbott
2018-07-18 21:10 ` [PATCH 2/2] arm64: Clear the stack Laura Abbott
2018-07-18 21:10   ` Laura Abbott
2018-07-19  2:20   ` Kees Cook
2018-07-19  2:20     ` Kees Cook
2018-07-19 10:41   ` Alexander Popov
2018-07-19 10:41     ` Alexander Popov
2018-07-19 11:41   ` Mark Rutland
2018-07-19 11:41     ` Mark Rutland
2018-02-21  1:13 [PATCH 0/2] Stackleak for arm64 Laura Abbott
2018-02-21  1:13 ` [PATCH 2/2] arm64: Clear the stack Laura Abbott
2018-02-21  1:13   ` Laura Abbott
2018-02-21 15:38   ` Mark Rutland
2018-02-21 15:38     ` Mark Rutland
2018-02-21 23:53     ` Laura Abbott
2018-02-21 23:53       ` Laura Abbott
2018-02-22  1:35       ` Laura Abbott
2018-02-22  1:35         ` Laura Abbott

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=4b7e94c1-79c9-0380-25c6-762762ed595f@redhat.com \
    --to=labbott@redhat.com \
    --cc=alex.popov@linux.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.