Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4;
From:   Haibo Li <haibo.li@mediatek.com>
To:     <andreyknvl@gmail.com>
CC:     <akpm@linux-foundation.org>,
        <angelogioacchino.delregno@collabora.com>, <dvyukov@google.com>,
        <glider@google.com>, <haibo.li@mediatek.com>, <jannh@google.com>,
        <kasan-dev@googlegroups.com>,
        <linux-arm-kernel@lists.infradead.org>,
        <linux-kernel@vger.kernel.org>,
        <linux-mediatek@lists.infradead.org>, <linux-mm@kvack.org>,
        <mark.rutland@arm.com>, <matthias.bgg@gmail.com>,
        <ryabinin.a.a@gmail.com>, <vincenzo.frascino@arm.com>,
        <xiaoming.yu@mediatek.com>
Subject: Re: [PATCH] kasan:fix access invalid shadow address when input is illegal
Date:   Fri, 15 Sep 2023 10:45:59 +0800
Message-ID: <20230915024559.32806-1-haibo.li@mediatek.com>
In-Reply-To: <CA+fCnZePgv=V65t4FtJvcyKvhM6yA3amTbPnwc5Ft5YdzpeeRg@mail.gmail.com>
References: <CA+fCnZePgv=V65t4FtJvcyKvhM6yA3amTbPnwc5Ft5YdzpeeRg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain
Precedence: bulk

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