linux-kernel - Re: [PATCH 3/3] arm64: mm: log potential KASAN shadow alias

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 2 Dec 2021 16:30:30 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     Andrey Konovalov <andreyknvl@...il.com>
Cc:     Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Alexander Potapenko <glider@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Andrey Ryabinin <ryabinin.a.a@...il.com>,
        Will Deacon <will@...nel.org>
Subject: Re: [PATCH 3/3] arm64: mm: log potential KASAN shadow alias

On Thu, Dec 02, 2021 at 05:20:56PM +0100, Andrey Konovalov wrote:
> On Thu, Dec 2, 2021 at 12:27 PM Mark Rutland <mark.rutland@....com> wrote:
> >
> > When the kernel is built with KASAN_GENERIC or KASAN_SW_TAGS, shadow
> > memory is allocated and mapped for all legitimate kernel addresses, and
> > prior to a regular memory access instrumentation will read from the
> > corresponding shadow address.
> >
> > Due to the way memory addresses are converted to shadow addresses,
> > bogus pointers (e.g. NULL) can generate shadow addresses out of the
> > bounds of allocated shadow memory. For example, with KASAN_GENERIC and
> > 48-bit VAs, NULL would have a shadow address of dfff800000000000, which
> > falls between the TTBR ranges.
> >
> > To make such cases easier to debug, this patch makes die_kernel_fault()
> > recover dump the real memory address range for any potential KASAN
> > shadow access. Since we can't reliably distinguish shadow accesses from
> > regular accesses, we always dump this information when shadow memory is
> > in use.

> > @@ -297,6 +297,12 @@ static void die_kernel_fault(const char *msg, unsigned long addr,
> >         pr_alert("Unable to handle kernel %s at virtual address %016lx\n", msg,
> >                  addr);
> >
> > +#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
> > +       pr_alert("Possible KASAN shadow access for range [%016lx..%016lx]\n",
> > +                (unsigned long)kasan_shadow_to_mem((void *)addr),
> > +                (unsigned long)kasan_shadow_to_mem((void *)addr + 1) - 1);
> > +#endif
> 
> Hi Mark,
> 
> There's the kasan_non_canonical_hook() function that's used on x86 for
> the same purpose: adding clarity to GPF faults caused by KASAN shadow
> accesses. Would it possible to reuse it for arm64?

Aha! That looks like exactly what I'm after; I'll go try that for v2.

Thanks for the pointer!

Mark.