Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
From:   Haibo Li <haibo.li@mediatek.com>
To:     <akpm@linux-foundation.org>
CC:     <andreyknvl@gmail.com>, <angelogioacchino.delregno@collabora.com>,
        <dvyukov@google.com>, <glider@google.com>, <haibo.li@mediatek.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>,
        <matthias.bgg@gmail.com>, <ryabinin.a.a@gmail.com>,
        <vincenzo.frascino@arm.com>, <xiaoming.yu@mediatek.com>,
        <jannh@google.com>
Subject: Re: [PATCH v2] kasan:print the original fault addr when access invalid shadow
Date:   Tue, 10 Oct 2023 09:52:16 +0800
Message-ID: <20231010015216.67121-1-haibo.li@mediatek.com>
In-Reply-To: <20231009170031.a294c11575d5d4941b8596a9@linux-foundation.org>
References: <20231009170031.a294c11575d5d4941b8596a9@linux-foundation.org>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain
Precedence: bulk

> On Mon, 9 Oct 2023 15:37:48 +0800 Haibo Li <haibo.li@mediatek.com> wrote:=
=0D
> =0D
> > when the checked address is illegal,the corresponding shadow address=0D
> > from kasan_mem_to_shadow may have no mapping in mmu table.=0D
> > Access such shadow address causes kernel oops.=0D
> > Here is a sample about oops on arm64(VA 39bit) =0D
> > with KASAN_SW_TAGS and KASAN_OUTLINE on:=0D
> > =0D
> > [ffffffb80aaaaaaa] pgd=3D000000005d3ce003, p4d=3D000000005d3ce003,=0D
> >     pud=3D000000005d3ce003, pmd=3D0000000000000000=0D
> > Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP=0D
> > Modules linked in:=0D
> > CPU: 3 PID: 100 Comm: sh Not tainted 6.6.0-rc1-dirty #43=0D
> > Hardware name: linux,dummy-virt (DT)=0D
> > pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=3D--)=0D
> > pc : __hwasan_load8_noabort+0x5c/0x90=0D
> > lr : do_ib_ob+0xf4/0x110=0D
> > ffffffb80aaaaaaa is the shadow address for efffff80aaaaaaaa.=0D
> > The problem is reading invalid shadow in kasan_check_range.=0D
> > =0D
> > The generic kasan also has similar oops.=0D
> > =0D
> > It only reports the shadow address which causes oops but not=0D
> > the original address.=0D
> > =0D
> > Commit 2f004eea0fc8("x86/kasan: Print original address on #GP")=0D
> > introduce to kasan_non_canonical_hook but limit it to KASAN_INLINE.=0D
> > =0D
> > This patch extends it to KASAN_OUTLINE mode.=0D
> =0D
> Is 2f004eea0fc8 a suitable Fixes: target for this?  If not, what is?=0D
> =0D
Yes, 2f004eea0fc8 is a suitable fix.=0D
All we need is a better crash report for this case.=0D
After commit 2f004eea0fc8 and commit =0D
07b742a4d912 ("arm64: mm: log potential KASAN shadow alias"),=0D
it is easy to understand the original address when=0D
 out-of-bounds KASAN shadow accesses occur.=0D
Currently, this feature is only available for the KASAN_INLINE case.=0D
As Jann said, it is also suitable for the KASAN_OUTLINE case.=0D
=0D
> Also, I'm assuming that we want to backport this fix into earlier=0D
> kernel versions?=0D
My opinion:=0D
 As it is to improve crash report,there is no requirement to backport.=0D