Messages in this thread | | | From | Andrey Ryabinin <> | Date | Tue, 2 Apr 2024 11:48:37 +0200 | Subject | Re: [PATCH] arm: kasan: clear stale stack poison |
| |
On Tue, Apr 2, 2024 at 11:36 AM Mark Rutland <mark.rutland@arm.com> wrote: .. > It looks like you're specifically referring to what arm64 did in commit: > > 0d97e6d8024c71cc ("arm64: kasan: clear stale stack poison") > > Where the commit message explained the problem: > > | Functions which the compiler has instrumented for KASAN place poison on > | the stack shadow upon entry and remove this poison prior to returning. > | > | In the case of cpuidle, CPUs exit the kernel a number of levels deep in > | C code. Any instrumented functions on this critical path will leave > | portions of the stack shadow poisoned. > | > | If CPUs lose context and return to the kernel via a cold path, we > | restore a prior context saved in __cpu_suspend_enter are forgotten, and > | we never remove the poison they placed in the stack shadow area by > | functions calls between this and the actual exit of the kernel. > | > | Thus, (depending on stackframe layout) subsequent calls to instrumented > | functions may hit this stale poison, resulting in (spurious) KASAN > | splats to the console. > | > | To avoid this, clear any stale poison from the idle thread for a CPU > | prior to bringing a CPU online. > > ... which we then extended to check for CONFIG_KASAN_STACK in commit: > > d56a9ef84bd0e1e8 ("kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK") > > If you can fold in the description above (i.e. cite commit 0d97e6d8024c71cc and > a copy of its commit message): > > Reviewed-by: Mark Rutland <mark.rutland@arm.com> >
Agreed with the above, feel free to add:
Acked-by: Andrey Ryabinin <ryabinin.a.a@gmail.com>
| |