> On Thu, Sep 14, 2023 at 10:41â?¯PM Jann Horn <jannh@xxxxxxxxxx> 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.