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 <[email protected]>
Signed-off-by: Lecopzer Chen <[email protected]>
---
arch/arm64/Kconfig | 1 +
1 file changed, 1 insertion(+)
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
--
2.25.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
> 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
On Tue, Mar 30, 2021 at 10:14 AM Lecopzer Chen
<[email protected]> 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