| Message ID | 20210109103252.812517-1-lecopzer@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: kasan: support CONFIG_KASAN_VMALLOC | expand |
Dear reviewers and maintainers, Could we have chance to upstream this in 5.12-rc? So if these patches have any problem I can fix as soon as possible before next -rc comming. thanks! BRs, Lecopzer
On Sat, Jan 9, 2021 at 11:33 AM Lecopzer Chen <lecopzer@gmail.com> 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. > > Test environment: > 4G and 8G Qemu virt, > 39-bit VA + 4k PAGE_SIZE with 3-level page table, > test by lib/test_kasan.ko and lib/test_kasan_module.ko > > It also works in Kaslr with CONFIG_RANDOMIZE_MODULE_REGION_FULL > and randomize module region inside vmalloc area. > > > [1]: commit 0609ae011deb41c ("x86/kasan: support KASAN_VMALLOC") > > Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com> > Acked-by: Andrey Konovalov <andreyknvl@google.com> > Tested-by: Andrey Konovalov <andreyknvl@google.com> > > > v2 -> v1 > 1. kasan_init.c tweak indent > 2. change Kconfig depends only on HAVE_ARCH_KASAN > 3. support randomized module region. > > v1: > https://lore.kernel.org/lkml/20210103171137.153834-1-lecopzer@gmail.com/ > > Lecopzer Chen (4): > arm64: kasan: don't populate vmalloc area for CONFIG_KASAN_VMALLOC > arm64: kasan: abstract _text and _end to KERNEL_START/END > arm64: Kconfig: support CONFIG_KASAN_VMALLOC > arm64: kaslr: support randomized module area with KASAN_VMALLOC > > arch/arm64/Kconfig | 1 + > arch/arm64/kernel/kaslr.c | 18 ++++++++++-------- > arch/arm64/kernel/module.c | 16 +++++++++------- > arch/arm64/mm/kasan_init.c | 29 +++++++++++++++++++++-------- > 4 files changed, 41 insertions(+), 23 deletions(-) > > -- > 2.25.1 > Hi Will, Could you PTAL at the arm64 changes? Thanks!
On Thu, Jan 21, 2021 at 06:44:14PM +0100, Andrey Konovalov wrote: > On Sat, Jan 9, 2021 at 11:33 AM Lecopzer Chen <lecopzer@gmail.com> 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. > > > > Test environment: > > 4G and 8G Qemu virt, > > 39-bit VA + 4k PAGE_SIZE with 3-level page table, > > test by lib/test_kasan.ko and lib/test_kasan_module.ko > > > > It also works in Kaslr with CONFIG_RANDOMIZE_MODULE_REGION_FULL > > and randomize module region inside vmalloc area. > > > > > > [1]: commit 0609ae011deb41c ("x86/kasan: support KASAN_VMALLOC") > > > > Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com> > > Acked-by: Andrey Konovalov <andreyknvl@google.com> > > Tested-by: Andrey Konovalov <andreyknvl@google.com> > > > > > > v2 -> v1 > > 1. kasan_init.c tweak indent > > 2. change Kconfig depends only on HAVE_ARCH_KASAN > > 3. support randomized module region. > > > > v1: > > https://lore.kernel.org/lkml/20210103171137.153834-1-lecopzer@gmail.com/ > > > > Lecopzer Chen (4): > > arm64: kasan: don't populate vmalloc area for CONFIG_KASAN_VMALLOC > > arm64: kasan: abstract _text and _end to KERNEL_START/END > > arm64: Kconfig: support CONFIG_KASAN_VMALLOC > > arm64: kaslr: support randomized module area with KASAN_VMALLOC > > > > arch/arm64/Kconfig | 1 + > > arch/arm64/kernel/kaslr.c | 18 ++++++++++-------- > > arch/arm64/kernel/module.c | 16 +++++++++------- > > arch/arm64/mm/kasan_init.c | 29 +++++++++++++++++++++-------- > > 4 files changed, 41 insertions(+), 23 deletions(-) > > > > -- > > 2.25.1 > > > > Hi Will, > > Could you PTAL at the arm64 changes? Sorry, wanted to get to this today but I ran out of time in the end. On the list for next week! Will
On Sat, 9 Jan 2021 at 11:33, Lecopzer Chen <lecopzer@gmail.com> 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. > > Test environment: > 4G and 8G Qemu virt, > 39-bit VA + 4k PAGE_SIZE with 3-level page table, > test by lib/test_kasan.ko and lib/test_kasan_module.ko > > It also works in Kaslr with CONFIG_RANDOMIZE_MODULE_REGION_FULL > and randomize module region inside vmalloc area. > > > [1]: commit 0609ae011deb41c ("x86/kasan: support KASAN_VMALLOC") > > Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com> > Acked-by: Andrey Konovalov <andreyknvl@google.com> > Tested-by: Andrey Konovalov <andreyknvl@google.com> > > > v2 -> v1 > 1. kasan_init.c tweak indent > 2. change Kconfig depends only on HAVE_ARCH_KASAN > 3. support randomized module region. > > v1: > https://lore.kernel.org/lkml/20210103171137.153834-1-lecopzer@gmail.com/ > > Lecopzer Chen (4): > arm64: kasan: don't populate vmalloc area for CONFIG_KASAN_VMALLOC > arm64: kasan: abstract _text and _end to KERNEL_START/END > arm64: Kconfig: support CONFIG_KASAN_VMALLOC > arm64: kaslr: support randomized module area with KASAN_VMALLOC > I failed to realize that VMAP_STACK and KASAN are currently mutually exclusive on arm64, and that this series actually fixes that, which is a big improvement, so it would make sense to call that out. This builds and runs fine for me on a VM running under KVM. Tested-by: Ard Biesheuvel <ardb@kernel.org>
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? Thanks, Will
> 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. BRs, Lecopzer
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
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... > oh, sorry I misunderstood your question. FWIW, I think this won't happend because this mean vmalloc() provides va which already allocated by kimg, as I know, vmalloc_init() will insert early allocated vma into its vmalloc rb tree > , and this early allocated vma will include kernel image. After quick review of mm init code, this early allocated for vma is at map_kernel() in arch/arm64/mm/mmu.c BRs Lecopzer
> 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... oh, sorry I misunderstood your question. FWIW, I think this won't happend because this mean vmalloc() provides va which already allocated by kimg, as I know, vmalloc_init() will insert early allocated vma into its vmalloc rb tree , and this early allocated vma will include kernel image. After quick review of mm init code, this early allocated for vma is at map_kernel() in arch/arm64/mm/mmu.c BRs Lecopzer
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. Test environment: 4G and 8G Qemu virt, 39-bit VA + 4k PAGE_SIZE with 3-level page table, test by lib/test_kasan.ko and lib/test_kasan_module.ko It also works in Kaslr with CONFIG_RANDOMIZE_MODULE_REGION_FULL and randomize module region inside vmalloc area. [1]: commit 0609ae011deb41c ("x86/kasan: support KASAN_VMALLOC") Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com> Acked-by: Andrey Konovalov <andreyknvl@google.com> Tested-by: Andrey Konovalov <andreyknvl@google.com> v2 -> v1 1. kasan_init.c tweak indent 2. change Kconfig depends only on HAVE_ARCH_KASAN 3. support randomized module region. v1: https://lore.kernel.org/lkml/20210103171137.153834-1-lecopzer@gmail.com/ Lecopzer Chen (4): arm64: kasan: don't populate vmalloc area for CONFIG_KASAN_VMALLOC arm64: kasan: abstract _text and _end to KERNEL_START/END arm64: Kconfig: support CONFIG_KASAN_VMALLOC arm64: kaslr: support randomized module area with KASAN_VMALLOC arch/arm64/Kconfig | 1 + arch/arm64/kernel/kaslr.c | 18 ++++++++++-------- arch/arm64/kernel/module.c | 16 +++++++++------- arch/arm64/mm/kasan_init.c | 29 +++++++++++++++++++++-------- 4 files changed, 41 insertions(+), 23 deletions(-)