diff mbox series

[v4,5/5] arm64: Kconfig: select KASAN_VMALLOC if KANSAN_GENERIC is enabled

Message ID 20210324040522.15548-6-lecopzer.chen@mediatek.com (mailing list archive)
State New, archived
Headers show
Series arm64: kasan: support CONFIG_KASAN_VMALLOC | expand

Commit Message

Lecopzer Chen March 24, 2021, 4:05 a.m. UTC 
Before this patch, someone who wants to use VMAP_STACK when
KASAN_GENERIC enabled must explicitly select KASAN_VMALLOC.

From Will's suggestion [1]:
  > I would _really_ like to move to VMAP stack unconditionally, and
  > that would effectively force KASAN_VMALLOC to be set if KASAN is in use

Because VMAP_STACK now depends on either HW_TAGS or KASAN_VMALLOC if
KASAN enabled, in order to make VMAP_STACK selected unconditionally,
we bind KANSAN_GENERIC and KASAN_VMALLOC together.

Note that SW_TAGS supports neither VMAP_STACK nor KASAN_VMALLOC now,
so this is the first step to make VMAP_STACK selected unconditionally.

Bind KANSAN_GENERIC and KASAN_VMALLOC together is supposed to cost more
memory at runtime, thus the alternative is using SW_TAGS KASAN instead.

[1]: https://lore.kernel.org/lkml/20210204150100.GE20815@willie-the-truck/

Suggested-by: Will Deacon <will@kernel.org>
Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

Comments

Will Deacon March 29, 2021, 12:54 p.m. UTC | #1 
On Wed, Mar 24, 2021 at 12:05:22PM +0800, Lecopzer Chen wrote:
> Before this patch, someone who wants to use VMAP_STACK when
> KASAN_GENERIC enabled must explicitly select KASAN_VMALLOC.
> 
> From Will's suggestion [1]:
>   > I would _really_ like to move to VMAP stack unconditionally, and
>   > that would effectively force KASAN_VMALLOC to be set if KASAN is in use
> 
> Because VMAP_STACK now depends on either HW_TAGS or KASAN_VMALLOC if
> KASAN enabled, in order to make VMAP_STACK selected unconditionally,
> we bind KANSAN_GENERIC and KASAN_VMALLOC together.
> 
> Note that SW_TAGS supports neither VMAP_STACK nor KASAN_VMALLOC now,
> so this is the first step to make VMAP_STACK selected unconditionally.

Do you know if anybody is working on this? It's really unfortunate that
we can't move exclusively to VMAP_STACK just because of SW_TAGS KASAN.

That said, what is there to do? As things stand, won't kernel stack
addresses end up using KASAN_TAG_KERNEL?

Will
Lecopzer Chen March 30, 2021, 8:14 a.m. UTC | #2 
> On Wed, Mar 24, 2021 at 12:05:22PM +0800, Lecopzer Chen wrote:
> > Before this patch, someone who wants to use VMAP_STACK when
> > KASAN_GENERIC enabled must explicitly select KASAN_VMALLOC.
> > 
> > From Will's suggestion [1]:
> >   > I would _really_ like to move to VMAP stack unconditionally, and
> >   > that would effectively force KASAN_VMALLOC to be set if KASAN is in use
> > 
> > Because VMAP_STACK now depends on either HW_TAGS or KASAN_VMALLOC if
> > KASAN enabled, in order to make VMAP_STACK selected unconditionally,
> > we bind KANSAN_GENERIC and KASAN_VMALLOC together.
> > 
> > Note that SW_TAGS supports neither VMAP_STACK nor KASAN_VMALLOC now,
> > so this is the first step to make VMAP_STACK selected unconditionally.
> 
> Do you know if anybody is working on this? It's really unfortunate that
> we can't move exclusively to VMAP_STACK just because of SW_TAGS KASAN.
> 
> That said, what is there to do? As things stand, won't kernel stack
> addresses end up using KASAN_TAG_KERNEL?


Hi Andrey,

Do you or any KASAN developers have already had any plan for this?



thanks,
Lecopzer
Andrey Konovalov March 30, 2021, 3:41 p.m. UTC | #3 
On Tue, Mar 30, 2021 at 10:14 AM Lecopzer Chen
<lecopzer.chen@mediatek.com> wrote:
>
> > Do you know if anybody is working on this? It's really unfortunate that
> > we can't move exclusively to VMAP_STACK just because of SW_TAGS KASAN.
> >
> > That said, what is there to do? As things stand, won't kernel stack
> > addresses end up using KASAN_TAG_KERNEL?
>
> Hi Andrey,
>
> Do you or any KASAN developers have already had any plan for this?

Hi Will and Lecopzer,

We have an issue open to track this [1], but no immediate plans to work on this.

Now that we have GENERIC vmalloc support for arm64, there's a chance
that SW_TAGS vmalloc will just work once allowed via configs. However,
I would expect that we'll still need to at least add some
kasan_reset_tag() annotations here and there.

Thanks!

[1] https://bugzilla.kernel.org/show_bug.cgi?id=211777
diff mbox series

Patch

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3e54fa938234..07762359d741 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -195,6 +195,7 @@  config ARM64
 	select IOMMU_DMA if IOMMU_SUPPORT
 	select IRQ_DOMAIN
 	select IRQ_FORCED_THREADING
+	select KASAN_VMALLOC if KASAN_GENERIC
 	select MODULES_USE_ELF_RELA
 	select NEED_DMA_MAP_STATE
 	select NEED_SG_DMA_LENGTH