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).
