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: <87pmr1r4vl.mognet@arm.com>
Date:   Mon, 15 Nov 2021 12:16:14 +0000
From:   Valentin Schneider <valentin.schneider@....com>
To:     Mark Rutland <mark.rutland@....com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Cc:     catalin.marinas@....com, dvyukov@...gle.com, mark.rutland@....com,
        peterz@...radead.org, quic_qiancai@...cinc.com, will@...nel.org,
        woodylin@...gle.com
Subject: Re: [PATCH] Reset task stack state in bringup_cpu()


Hi Mark,

Thanks for tackling this and glueing the pieces back together. LGTM, though
I couldn't stop myself from playing changelog police - I also have a
question/comment wrt the BP.

On 15/11/21 11:33, Mark Rutland wrote:
> To hot unplug a CPU, the idle task on that CPU calls a few layers of C
> code before finally leaving the kernel. When KASAN is in use, poisoned
> shadow is left around for each of the active stack frames, and when
> shadow call stacks are in use. When shadow call stacks are in use the
> task's SCS SP is left pointing at an arbitrary point within the task's
> shadow call stack.
>
> When an offlines CPU is hotlpugged back into the kernel, this stale
          ^^^^^^^^        ^^^^^^^^^^
          offlined?       hotplugged

> state can adversely affect the newly onlined CPU. Stale KASAN shadow can
> alias new stackframes and result in bogus KASAN warnings. A stale SCS SP
> is effectively a memory leak, and prevents a portion of the shadow call
> stack being used. Across a number of hotplug cycles the task's entire
> shadow call stack can become unusable.
>
> We previously fixed the KASAN issue in commit:
>
>   e1b77c92981a5222 ("sched/kasan: remove stale KASAN poison after hotplug")
>
> In commit:
>
>   f1a0a376ca0c4ef1 ("sched/core: Initialize the idle task with preemption disabled")
>
> ... we broke both KASAN and SCS, with SCS being fixed up in commit:
>
>   63acd42c0d4942f7 ("sched/scs: Reset the shadow stack when idle_task_exit")
>
> ... but as this runs in the context of the idle task being offlines it's
                                                             ^^^^^^^^
                                                             offlined

> potentially fragile.
>
> Fix both of these consistently and more robustly by resetting the SCS SP
> and KASAN shadow immediately before we online a CPU. This ensures the
> idle task always has a consistent state, and removes the need to do so
> when initializing an idle task or when unplugging an idle task.
>
> I've tested this with both GCC and clang, with reelvant options enabled,
                                                 ^^^^^^^^
                                                 relevant

> offlining and online CPUs with:
                ^^^^^^
                onlining

>
> | while true; do
> |   for C in /sys/devices/system/cpu/cpu*/online; do
> |     echo 0 > $C;
> |     echo 1 > $C;
> |   done
> | done
>
> Link: https://lore.kernel.org/lkml/20211012083521.973587-1-woodylin@google.com/
> Link: https://lore.kernel.org/linux-arm-kernel/YY9ECKyPtDbD9q8q@qian-HP-Z2-SFF-G5-Workstation/
> Fixes: 1a0a376ca0c4ef1 ("sched/core: Initialize the idle task with preemption disabled")
> Reported-by: Qian Cai <quic_qiancai@...cinc.com>
> Signed-off-by: Mark Rutland <mark.rutland@....com>
> Cc: Catalin Marinas <catalin.marinas@....com>
> Cc: Dmitry Vyukov <dvyukov@...gle.com>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Valentin Schneider <valentin.schneider@....com>
> Cc: Will Deacon <will@...nel.org>
> Cc: Woody Lin <woodylin@...gle.com>

Reviewed-by: Valentin Schneider <valentin.schneider@....com>

> ---
>  kernel/cpu.c        | 7 +++++++
>  kernel/sched/core.c | 4 ----
>  2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index 192e43a87407..407a2568f35e 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -31,6 +31,7 @@
>  #include <linux/smpboot.h>
>  #include <linux/relay.h>
>  #include <linux/slab.h>
> +#include <linux/scs.h>
>  #include <linux/percpu-rwsem.h>
>  #include <linux/cpuset.h>
>
> @@ -588,6 +589,12 @@ static int bringup_cpu(unsigned int cpu)
>       int ret;
>
>       /*
> +	 * Reset stale stack state from the last time this CPU was online.
> +	 */
> +	scs_task_reset(idle);
> +	kasan_unpoison_task_stack(idle);
> +
> +	/*
>        * Some architectures have to walk the irq descriptors to
>        * setup the vector space for the cpu which comes online.
>        * Prevent irq alloc/free across the bringup.
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 3c9b0fda64ac..76f9deeaa942 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -8619,9 +8619,6 @@ void __init init_idle(struct task_struct *idle, int cpu)
>       idle->flags |= PF_IDLE | PF_KTHREAD | PF_NO_SETAFFINITY;
>       kthread_set_per_cpu(idle, cpu);
>
> -	scs_task_reset(idle);
> -	kasan_unpoison_task_stack(idle);
> -

So those are no longer invoked for the BP during bootup (via sched_init());
that looks OK for KASAN per:

  e1b77c92981a ("sched/kasan: remove stale KASAN poison after hotplug")

I didn't find any explicit commit for SCS but from the looks of
arm64/include/asm/thread_info.h we seem to be initializing things
correctly, so IIUC the removed hunk wasn't actually necessary for the BP's
first boot.

>  #ifdef CONFIG_SMP
>       /*
>        * It's possible that init_idle() gets called multiple times on a task,
> @@ -8777,7 +8774,6 @@ void idle_task_exit(void)
>               finish_arch_post_lock_switch();
>       }
>
> -	scs_task_reset(current);
>       /* finish_cpu(), as ran on the BP, will clean up the active_mm state */
>  }
>
> --
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ