linux-kernel - Re: [PATCH] kasan:fix access invalid shadow address when input is illegal

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: <20230915024559.32806-1-haibo.li@mediatek.com>
Date:   Fri, 15 Sep 2023 10:45:59 +0800
From:   Haibo Li <haibo.li@...iatek.com>
To:     <andreyknvl@...il.com>
CC:     <akpm@...ux-foundation.org>,
        <angelogioacchino.delregno@...labora.com>, <dvyukov@...gle.com>,
        <glider@...gle.com>, <haibo.li@...iatek.com>, <jannh@...gle.com>,
        <kasan-dev@...glegroups.com>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>,
        <linux-mediatek@...ts.infradead.org>, <linux-mm@...ck.org>,
        <mark.rutland@....com>, <matthias.bgg@...il.com>,
        <ryabinin.a.a@...il.com>, <vincenzo.frascino@....com>,
        <xiaoming.yu@...iatek.com>
Subject: Re: [PATCH] kasan:fix access invalid shadow address when input is illegal

> On Thu, Sep 14, 2023 at 10:41 PM Jann Horn <jannh@...gle.com> wrote:
> >
> > > Accessing unmapped memory with KASAN always led to a crash when
> > > checking shadow memory. This was reported/discussed before. To improve
> > > crash reporting for this case, Jann added kasan_non_canonical_hook and
> > > Mark integrated it into arm64. But AFAIU, for some reason, it stopped
> > > working.
> > >
> > > Instead of this patch, we need to figure out why
> > > kasan_non_canonical_hook stopped working and fix it.
> > >
> > > This approach taken by this patch won't work for shadow checks added
> > > by compiler instrumentation. It only covers explicitly checked
> > > accesses, such as via memcpy, etc.
> >
> > FWIW, AFAICS kasan_non_canonical_hook() currently only does anything
> > under CONFIG_KASAN_INLINE;
> 
> Ah, right. I was thinking about the inline mode, but the patch refers
> to the issue with the outline mode.
> 
> However, I just checked kasan_non_canonical_hook for SW_TAGS with the
> inline mode: it does not work when accessing 0x42ffffb80aaaaaaa, the
> addr < KASAN_SHADOW_OFFSET check fails. It appears there's something
> unusual about how instrumentation calculates the shadow address. I
> didn't investigate further yet.
> 
> > I think the idea when I added that was that
> > it assumes that when KASAN checks an access in out-of-line
> > instrumentation or a slowpath, it will do the required checks to avoid
> > this kind of fault?
> 
> Ah, no, KASAN doesn't do it.
> 
> However, I suppose we could add what the original patch proposes for
> the outline mode. For the inline mode, it seems to be pointless, as
> most access checks happen though the compiler inserted code anyway.
> 
> I also wonder how much slowdown this patch will introduce.
> 
> Haibo, could you check how much slower the kernel becomes with your
> patch? If possible, with all GENERIC/SW_TAGS and INLINE/OUTLINE
> combinations.
> 
> If the slowdown is large, we can just make kasan_non_canonical_hook
> work for both modes (and fix it for SW_TAGS).

Thanks.
The patch checks each shadow address,so it introduces extra overhead.
Now kasan_non_canonical_hook only works for CONFIG_KASAN_INLINE.
And CONFIG_KASAN_OUTLINE is set in my case.
Is it possible to make kasan_non_canonical_hook works for both 
INLINE and OUTLINE by simply remove the "#ifdef CONFIG_KASAN_INLINE"?
Since kasan_non_canonical_hook is only used after kernel fault,it 
is better if there is no limit.