+ arm64-entry-use-stackleak_erase_on_task_stack.patch added to -mm tree

+ arm64-entry-use-stackleak_erase_on_task_stack.patch added to -mm tree

[Andrew Morton]

The patch titled
     Subject: arm64: entry: use stackleak_erase_on_task_stack()
has been added to the -mm tree.  Its filename is
     arm64-entry-use-stackleak_erase_on_task_stack.patch

This patch should soon appear at
    https://ozlabs.org/~akpm/mmots/broken-out/arm64-entry-use-stackleak_erase_on_task_stack.patch
and later at
    https://ozlabs.org/~akpm/mmotm/broken-out/arm64-entry-use-stackleak_erase_on_task_stack.patch

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***

The -mm tree is included into linux-next and is updated
there every 3-4 working days

------------------------------------------------------
From: Mark Rutland <mark.rutland@arm.com>
Subject: arm64: entry: use stackleak_erase_on_task_stack()

On arm64 we always call stackleak_erase() on a task stack, and never call
it on another stack.  We can avoid some redundant work by using
stackleak_erase_on_task_stack(), telling the stackleak code that it's
being called on a task stack.

Link: https://lkml.kernel.org/r/20220425115603.781311-9-mark.rutland@arm.com
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Alexander Popov <alex.popov@linux.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 arch/arm64/kernel/entry.S |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm64/kernel/entry.S~arm64-entry-use-stackleak_erase_on_task_stack
+++ a/arch/arm64/kernel/entry.S
@@ -596,7 +596,7 @@ SYM_CODE_START_LOCAL(ret_to_user)
 	ldr	x19, [tsk, #TSK_TI_FLAGS]	// re-check for single-step
 	enable_step_tsk x19, x2
 #ifdef CONFIG_GCC_PLUGIN_STACKLEAK
-	bl	stackleak_erase
+	bl	stackleak_erase_on_task_stack
 #endif
 	kernel_exit 0
 SYM_CODE_END(ret_to_user)
_

Patches currently in -mm which might be from mark.rutland@arm.com are

arm64-stackleak-fix-current_top_of_stack.patch
stackleak-move-skip_erasing-check-earlier.patch
stackleak-rework-stack-low-bound-handling.patch
stackleak-clarify-variable-names.patch
stackleak-rework-stack-high-bound-handling.patch
stackleak-remove-redundant-check.patch
stackleak-add-on-off-stack-variants.patch
arm64-entry-use-stackleak_erase_on_task_stack.patch

Re: + arm64-entry-use-stackleak_erase_on_task_stack.patch added to -mm tree

[Kees Cook]

Hi,

I don't think these should be applied to -mm. They would normally go via
my hardening tree (with other gcc plugins), but also Mark is going to be
spinning a v2...

-Kees

On Tue, Apr 26, 2022 at 01:51:41PM -0700, Andrew Morton wrote:
> 
> The patch titled
>      Subject: arm64: entry: use stackleak_erase_on_task_stack()
> has been added to the -mm tree.  Its filename is
>      arm64-entry-use-stackleak_erase_on_task_stack.patch
> 
> This patch should soon appear at
>     https://ozlabs.org/~akpm/mmots/broken-out/arm64-entry-use-stackleak_erase_on_task_stack.patch
> and later at
>     https://ozlabs.org/~akpm/mmotm/broken-out/arm64-entry-use-stackleak_erase_on_task_stack.patch
> 
> Before you just go and hit "reply", please:
>    a) Consider who else should be cc'ed
>    b) Prefer to cc a suitable mailing list as well
>    c) Ideally: find the original patch on the mailing list and do a
>       reply-to-all to that, adding suitable additional cc's
> 
> *** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
> 
> The -mm tree is included into linux-next and is updated
> there every 3-4 working days
> 
> ------------------------------------------------------
> From: Mark Rutland <mark.rutland@arm.com>
> Subject: arm64: entry: use stackleak_erase_on_task_stack()
> 
> On arm64 we always call stackleak_erase() on a task stack, and never call
> it on another stack.  We can avoid some redundant work by using
> stackleak_erase_on_task_stack(), telling the stackleak code that it's
> being called on a task stack.
> 
> Link: https://lkml.kernel.org/r/20220425115603.781311-9-mark.rutland@arm.com
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Alexander Popov <alex.popov@linux.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Will Deacon <will@kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  arch/arm64/kernel/entry.S |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/arch/arm64/kernel/entry.S~arm64-entry-use-stackleak_erase_on_task_stack
> +++ a/arch/arm64/kernel/entry.S
> @@ -596,7 +596,7 @@ SYM_CODE_START_LOCAL(ret_to_user)
>  	ldr	x19, [tsk, #TSK_TI_FLAGS]	// re-check for single-step
>  	enable_step_tsk x19, x2
>  #ifdef CONFIG_GCC_PLUGIN_STACKLEAK
> -	bl	stackleak_erase
> +	bl	stackleak_erase_on_task_stack
>  #endif
>  	kernel_exit 0
>  SYM_CODE_END(ret_to_user)
> _
> 
> Patches currently in -mm which might be from mark.rutland@arm.com are
> 
> arm64-stackleak-fix-current_top_of_stack.patch
> stackleak-move-skip_erasing-check-earlier.patch
> stackleak-rework-stack-low-bound-handling.patch
> stackleak-clarify-variable-names.patch
> stackleak-rework-stack-high-bound-handling.patch
> stackleak-remove-redundant-check.patch
> stackleak-add-on-off-stack-variants.patch
> arm64-entry-use-stackleak_erase_on_task_stack.patch
> 

-- 
Kees Cook

Re: + arm64-entry-use-stackleak_erase_on_task_stack.patch added to -mm tree

[Andrew Morton]

On Tue, 26 Apr 2022 14:18:20 -0700 Kees Cook <keescook@chromium.org> wrote:

> I don't think these should be applied to -mm. They would normally go via
> my hardening tree (with other gcc plugins), but also Mark is going to be
> spinning a v2...

Yep, sorry, that was a brainfart.