linux-kernel - Re: KASAN vs vmapped stacks

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: <CALCETrXOZ_SvAfX41NRZSU5m4A_vpRAANxB8VH_W_4DULqibkA@mail.gmail.com>
Date:	Mon, 11 Jul 2016 07:52:28 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Dmitry Vyukov <dvyukov@...gle.com>
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 Mon, Jul 11, 2016 at 1:30 AM, Dmitry Vyukov <dvyukov@...gle.com> wrote:
> 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?

It's a patchset I'm working on, and I'm hoping to get them in to 4.8.
They're only supported (so far) on x86, and they're enabled by a
config option.  The init task has a conventional stack, but all other
stacks are vmalloced.

> 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.

That's what I'm doing right now.  Enabling virtually mapped stacks
gives reliably stack overflow detection and avoids needing
higher-order pages.  It's certainly not a critical feature, but it's
nice, and supporting both it and KASAN at the same time would be nice.

--Andy