[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+aXMDDMWctFx9O+3hwS2QYBUfSXzsVGA8Ecbpu4mhVa2Q@mail.gmail.com>
Date: Mon, 11 Jul 2016 10:30:05 +0200
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
kasan-dev <kasan-dev@...glegroups.com>, X86 ML <x86@...nel.org>,
Alexander Potapenko <glider@...gle.com>,
Kees Cook <keescook@...omium.org>,
Borislav Petkov <bp@...en8.de>
Subject: Re: KASAN vs vmapped stacks
On Sun, Jul 10, 2016 at 2:47 PM, Andy Lutomirski <luto@...capital.net> 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.
>
> 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?
Hi Andy,
What is "virtually mapped stacks"? How are they enabled?
KASAN does not have real shadow for vmalloc range. Fixing this will
probably involve allocating real shadow memory for that range which
will increase memory consumption.
You said that you disabled the virtually mapped stacks, which means
that it is not a critical feature for your environment. When is it
supposed to be used? What are the benefits? For now I am leaning
towards automatically disabling virtually mapped stacks when KASAN is
enabled.
Thanks for the report
Powered by blists - more mailing lists