On Thu, Feb 04, 2021 at 11:53:46PM +0800, Lecopzer Chen wrote:
> > On Sat, Jan 09, 2021 at 06:32:48PM +0800, Lecopzer Chen wrote:
> > > Linux supports KAsan for VMALLOC since commit 3c5c3cfb9ef4da9
> > > ("kasan: support backing vmalloc space with real shadow memory")
> > >
> > > Acroding to how x86 ported it [1], they early allocated p4d and pgd,
> > > but in arm64 I just simulate how KAsan supports MODULES_VADDR in arm64
> > > by not to populate the vmalloc area except for kimg address.
> >
> > The one thing I've failed to grok from your series is how you deal with
> > vmalloc allocations where the shadow overlaps with the shadow which has
> > already been allocated for the kernel image. Please can you explain?
>
>
> The most key point is we don't map anything in the vmalloc shadow address.
> So we don't care where the kernel image locate inside vmalloc area.
>
> kasan_map_populate(kimg_shadow_start, kimg_shadow_end,...)
>
> Kernel image was populated with real mapping in its shadow address.
> I `bypass' the whole shadow of vmalloc area, the only place you can find
> about vmalloc_shadow is
> kasan_populate_early_shadow((void *)vmalloc_shadow_end,
> (void *)KASAN_SHADOW_END);
>
> ----------- vmalloc_shadow_start
> | |
> | |
> | | <= non-mapping
> | |
> | |
> |-----------|
> |///////////|<- kimage shadow with page table mapping.
> |-----------|
> | |
> | | <= non-mapping
> | |
> ------------- vmalloc_shadow_end
> |00000000000|
> |00000000000| <= Zero shadow
> |00000000000|
> ------------- KASAN_SHADOW_END
>
> vmalloc shadow will be mapped 'ondemend', see kasan_populate_vmalloc()
> in mm/vmalloc.c in detail.
> So the shadow of vmalloc will be allocated later if anyone use its va.
Indeed, but the question I'm asking is what happens when an on-demand shadow
allocation from vmalloc overlaps with the shadow that we allocated early for
the kernel image?
Sounds like I have to go and read the code...
Will
