[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <57836D8F.3020104@virtuozzo.com>
Date: Mon, 11 Jul 2016 12:57:35 +0300
From: Andrey Ryabinin <aryabinin@...tuozzo.com>
To: Andy Lutomirski <luto@...capital.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
kasan-dev <kasan-dev@...glegroups.com>, X86 ML <x86@...nel.org>,
Alexander Potapenko <glider@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Kees Cook <keescook@...omium.org>,
Borislav Petkov <bp@...en8.de>
Subject: Re: KASAN vs vmapped stacks
On 07/10/2016 03:47 PM, Andy Lutomirski wrote:
> Hi all-
>
> I found two nasty issues with virtually mapped stacks if KASAN is
> enabled. The first issue is a crash: the first non-init stack is
> allocated and accessed before KASAN initializes its zero shadow
> AFAICT, which means that we switch to that stack and then blow up when
> we start recursively faulting on failed accesses to the shadow.
>
KASAN initialized quite early, before any non-init task exists. The crash happens
because non-init task writes to write-protected zero shadow.
Currently KASAN doesn't allocate shadow memory for vmalloc addresses, we just map single
zero page and write protect it.
> The second issue is that, even if we survive (we initialize the zero
> shadow on time), KASAN will fail to protect hte stack.
>
> For now, I just disabled use of virtually mapped stacks if KASAN is
> on. Do you have any easy ideas to fix it?
>
Allocate shadow memory which backs vmalloc/vmap allocations is the only way to fix this.
I can do this, and post the patches soon enough.
> Thanks,
> Andy
>
Powered by blists - more mailing lists