linux-kernel - Re: Making KASAN compatible with VMAP

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]

Date:   Mon, 23 Jul 2018 12:18:13 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Alexander Potapenko <glider@...gle.com>,
        kasan-dev <kasan-dev@...glegroups.com>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>
Subject: Re: Making KASAN compatible with VMAP_STACK

On Mon, Jul 23, 2018 at 09:40:36AM +0200, Dmitry Vyukov wrote:
> On Sun, Jul 22, 2018 at 7:52 PM, Andy Lutomirski <luto@...nel.org> wrote:
> > Hi all-
> >
> > It would be really nice to make KASAN compatible with VMAP_STACK.
> > Both are valuable memory debugging features, and the fact that you
> > can't use both is disappointing.
> >
> > As far as I know, there are only two problems:
> >
> > 1. The KASAN shadow population code is a mess, and adding *anything*
> > to the KASAN shadow requires magical, fragile incantations.  It should
> > be cleaned up so that ranges can be easily populated without needing
> > to very carefully align things, call helpers in the right order, etc.
> > The core KASAN code should figure it out by itself.
> >
> > 2. The vmalloc area is potentially extremely large.  It might be
> > necessary to have a way to *depopulate* shadow space when stacks get
> > freed or, more generally, when vmap areas are freed.  Ideally KASAN
> > would integrate with the core vmalloc/vmap code and it would Just Work
> > (tm).  And, as a bonus, we'd get proper KASAN protection of vmalloced
> > memory.
> >
> > Any volunteers to fix this?
> 
> Hi Andy,
> 
> I understand that having most configs as orthogonal settings that can
> be enabled independently is generally good in intself, but I would
> like to understand what does VMAP_STACK add on top of KASAN in terms
> of debugging capabilities?

VMAP_STACK makes it possible to detect stack overflows reliably at the
point of overflow.

KASAN can't handle this reliably, even if it detects that an access is
out of the stack bounds, since handling this requires stack space.
Depending on a number of factors, this may be reported, might result in
recursive exceptions, etc.

I assume we must populate shadow  for vmalloc regions today, but I guess
that just shares the zero shadow?

Thanks,
Mark.