From: Andrey Ryabinin <aryabinin@virtuozzo.com> To: Daniel Axtens <dja@axtens.net>, kasan-dev@googlegroups.com, linux-mm@kvack.org, x86@kernel.org, glider@google.com, luto@kernel.org, linux-kernel@vger.kernel.org, mark.rutland@arm.com, dvyukov@google.com, christophe.leroy@c-s.fr Cc: linuxppc-dev@lists.ozlabs.org, gor@linux.ibm.com, Andrew Morton <akpm@linux-foundation.org> Subject: Re: [PATCH v10 3/5] fork: support VMAP_STACK with KASAN_VMALLOC Date: Tue, 29 Oct 2019 20:07:09 +0300 [thread overview] Message-ID: <6dd97cbd-b3ac-3f53-36d6-489c45ddaf92@virtuozzo.com> (raw) In-Reply-To: <20191029042059.28541-4-dja@axtens.net> On 10/29/19 7:20 AM, Daniel Axtens wrote: > Supporting VMAP_STACK with KASAN_VMALLOC is straightforward: > > - clear the shadow region of vmapped stacks when swapping them in > - tweak Kconfig to allow VMAP_STACK to be turned on with KASAN > > Reviewed-by: Dmitry Vyukov <dvyukov@google.com> > Signed-off-by: Daniel Axtens <dja@axtens.net> > --- Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com> > > diff --git a/kernel/fork.c b/kernel/fork.c > index 954e875e72b1..a6e5249ad74b 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -94,6 +94,7 @@ > #include <linux/livepatch.h> > #include <linux/thread_info.h> > #include <linux/stackleak.h> > +#include <linux/kasan.h> > > #include <asm/pgtable.h> > #include <asm/pgalloc.h> > @@ -224,6 +225,9 @@ static unsigned long *alloc_thread_stack_node(struct task_struct *tsk, int node) > if (!s) > continue; > > + /* Clear the KASAN shadow of the stack. */ > + kasan_unpoison_shadow(s->addr, THREAD_SIZE); > + Just sharing the thought. We could possibly add poisoning in free_thread_stack() to catch possible usage of freed cached stack. But it might be a bad idea because cached stacks supposed to be reused very quickly. So it might just add overhead without much gain. > /* Clear stale pointers from reused stack. */ > memset(s->addr, 0, THREAD_SIZE); > >
WARNING: multiple messages have this Message-ID (diff)
From: Andrey Ryabinin <aryabinin@virtuozzo.com> To: Daniel Axtens <dja@axtens.net>, kasan-dev@googlegroups.com, linux-mm@kvack.org, x86@kernel.org, glider@google.com, luto@kernel.org, linux-kernel@vger.kernel.org, mark.rutland@arm.com, dvyukov@google.com, christophe.leroy@c-s.fr Cc: Andrew Morton <akpm@linux-foundation.org>, linuxppc-dev@lists.ozlabs.org, gor@linux.ibm.com Subject: Re: [PATCH v10 3/5] fork: support VMAP_STACK with KASAN_VMALLOC Date: Tue, 29 Oct 2019 20:07:09 +0300 [thread overview] Message-ID: <6dd97cbd-b3ac-3f53-36d6-489c45ddaf92@virtuozzo.com> (raw) In-Reply-To: <20191029042059.28541-4-dja@axtens.net> On 10/29/19 7:20 AM, Daniel Axtens wrote: > Supporting VMAP_STACK with KASAN_VMALLOC is straightforward: > > - clear the shadow region of vmapped stacks when swapping them in > - tweak Kconfig to allow VMAP_STACK to be turned on with KASAN > > Reviewed-by: Dmitry Vyukov <dvyukov@google.com> > Signed-off-by: Daniel Axtens <dja@axtens.net> > --- Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com> > > diff --git a/kernel/fork.c b/kernel/fork.c > index 954e875e72b1..a6e5249ad74b 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -94,6 +94,7 @@ > #include <linux/livepatch.h> > #include <linux/thread_info.h> > #include <linux/stackleak.h> > +#include <linux/kasan.h> > > #include <asm/pgtable.h> > #include <asm/pgalloc.h> > @@ -224,6 +225,9 @@ static unsigned long *alloc_thread_stack_node(struct task_struct *tsk, int node) > if (!s) > continue; > > + /* Clear the KASAN shadow of the stack. */ > + kasan_unpoison_shadow(s->addr, THREAD_SIZE); > + Just sharing the thought. We could possibly add poisoning in free_thread_stack() to catch possible usage of freed cached stack. But it might be a bad idea because cached stacks supposed to be reused very quickly. So it might just add overhead without much gain. > /* Clear stale pointers from reused stack. */ > memset(s->addr, 0, THREAD_SIZE); > >
next prev parent reply other threads:[~2019-10-29 17:07 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-29 4:20 [PATCH v10 0/5] kasan: support backing vmalloc space with real shadow memory Daniel Axtens 2019-10-29 4:20 ` [PATCH v10 1/5] " Daniel Axtens 2019-10-29 16:42 ` Andrey Ryabinin 2019-10-29 16:42 ` Andrey Ryabinin 2019-10-30 14:29 ` Uladzislau Rezki 2019-10-30 14:29 ` Uladzislau Rezki 2019-10-31 9:36 ` Daniel Axtens 2019-10-31 9:36 ` Daniel Axtens 2019-10-29 4:20 ` [PATCH v10 2/5] kasan: add test for vmalloc Daniel Axtens 2019-10-29 16:43 ` Andrey Ryabinin 2019-10-29 4:20 ` [PATCH v10 3/5] fork: support VMAP_STACK with KASAN_VMALLOC Daniel Axtens 2019-10-29 17:07 ` Andrey Ryabinin [this message] 2019-10-29 17:07 ` Andrey Ryabinin 2019-10-29 4:20 ` [PATCH v10 4/5] x86/kasan: support KASAN_VMALLOC Daniel Axtens 2019-10-29 17:21 ` Andrey Ryabinin 2019-10-29 17:21 ` Andrey Ryabinin 2019-10-30 13:50 ` Daniel Axtens 2019-10-30 13:50 ` Daniel Axtens 2019-10-30 14:12 ` Andrey Ryabinin 2019-10-30 14:12 ` Andrey Ryabinin 2019-10-30 14:21 ` Daniel Axtens 2019-10-30 14:21 ` Daniel Axtens 2019-10-29 4:20 ` [PATCH v10 5/5] kasan debug: track pages allocated for vmalloc shadow Daniel Axtens 2019-10-29 17:34 ` Andrey Ryabinin 2019-10-29 17:34 ` Andrey Ryabinin
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=6dd97cbd-b3ac-3f53-36d6-489c45ddaf92@virtuozzo.com \ --to=aryabinin@virtuozzo.com \ --cc=akpm@linux-foundation.org \ --cc=christophe.leroy@c-s.fr \ --cc=dja@axtens.net \ --cc=dvyukov@google.com \ --cc=glider@google.com \ --cc=gor@linux.ibm.com \ --cc=kasan-dev@googlegroups.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=luto@kernel.org \ --cc=mark.rutland@arm.com \ --cc=x86@kernel.org \ /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: linkBe 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.