All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lecopzer Chen <lecopzer.chen@mediatek.com>
To: <linux@armlinux.org.uk>
Cc: <andreyknvl@gmail.com>, <anshuman.khandual@arm.com>,
	<ardb@kernel.org>, <arnd@arndb.de>, <dvyukov@google.com>,
	<geert+renesas@glider.be>, <glider@google.com>,
	<kasan-dev@googlegroups.com>, <lecopzer.chen@mediatek.com>,
	<linus.walleij@linaro.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <lukas.bulwahn@gmail.com>,
	<mark.rutland@arm.com>, <masahiroy@kernel.org>,
	<matthias.bgg@gmail.com>, <ryabinin.a.a@gmail.com>,
	<yj.chiang@mediatek.com>
Subject: Re: [PATCH v3 0/2] arm: kasan: support CONFIG_KASAN_VMALLOC
Date: Fri, 11 Mar 2022 18:52:15 +0800	[thread overview]
Message-ID: <20220311105215.5408-1-lecopzer.chen@mediatek.com> (raw)
In-Reply-To: <YismXDtUZ2cPtVnN@shell.armlinux.org.uk>

> On Fri, Mar 11, 2022 at 12:08:52AM +0100, Linus Walleij wrote:
> > On Sun, Feb 27, 2022 at 2:48 PM Lecopzer Chen
> > <lecopzer.chen@mediatek.com> wrote:
> > 
> > > Since the framework of KASAN_VMALLOC is well-developed,
> > > It's easy to support for ARM that simply not to map shadow of VMALLOC
> > > area on kasan_init.
> > >
> > > Since the virtual address of vmalloc for Arm is also between
> > > MODULE_VADDR and 0x100000000 (ZONE_HIGHMEM), which means the shadow
> > > address has already included between KASAN_SHADOW_START and
> > > KASAN_SHADOW_END.
> > > Thus we need to change nothing for memory map of Arm.
> > >
> > > This can fix ARM_MODULE_PLTS with KASan, support KASan for higmem
> > > and provide the first step to support CONFIG_VMAP_STACK with Arm.
> > >
> > >
> > > Test on
> > > 1. Qemu with memory 2G and vmalloc=500M for 3G/1G mapping.
> > > 2. Qemu with memory 2G and vmalloc=500M for 3G/1G mapping + LPAE.
> > > 3. Qemu with memory 2G and vmalloc=500M for 2G/2G mapping.
> > >
> > > v3:
> > >     rebase on 5.17-rc5.
> > >     Add simple doc for "arm: kasan: support CONFIG_KASAN_VMALLOC"
> > >     Tweak commit message.
> > 
> > Ater testing this with my kernel-in-vmalloc patches and some hacks, I got
> > the kernel booting in the VMALLOC area with KASan enabled!
> > See:
> > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kernel-in-vmalloc-v5.17-rc1
> > 
> > That's a pretty serious stress test. So:
> > Tested-by: Linus Walleij <linus.walleij@linaro.org>
> > Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> > for the series.
> > 
> > I suppose you could put this into Russell's patch tracker, it's gonna be
> > for kernel v5.19 by now but why stress. It seems I can fix up
> > kernel-in-vmalloc on top and submit that for v5.19 as well.
> 
> Ard's series already adds vmap stack support (which we've been doing
> some last minute panic-debugging on to get it ready for this merge
> window), but the above description makes it sound like this series is
> a pre-requisit for that.
> 
> Is it? Will Ard's work cause further regressions because this series
> isn't merged.
> 
> Please clarify - and urgently, there is not much time left before the
> merge window opens.
> 

Sorry I didn't describe it clearly,

config VMAP_STACK
  default y
  bool "Use a virtually-mapped stack"
  depends on HAVE_ARCH_VMAP_STACK
  depends on !KASAN || KASAN_HW_TAGS || KASAN_VMALLOC

This means KASAN can support with VMAP_STACK=y



BRs,
Lecopzer

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Lecopzer Chen <lecopzer.chen@mediatek.com>
To: <linux@armlinux.org.uk>
Cc: <andreyknvl@gmail.com>, <anshuman.khandual@arm.com>,
	<ardb@kernel.org>, <arnd@arndb.de>, <dvyukov@google.com>,
	<geert+renesas@glider.be>, <glider@google.com>,
	<kasan-dev@googlegroups.com>, <lecopzer.chen@mediatek.com>,
	<linus.walleij@linaro.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <lukas.bulwahn@gmail.com>,
	<mark.rutland@arm.com>, <masahiroy@kernel.org>,
	<matthias.bgg@gmail.com>, <ryabinin.a.a@gmail.com>,
	<yj.chiang@mediatek.com>
Subject: Re: [PATCH v3 0/2] arm: kasan: support CONFIG_KASAN_VMALLOC
Date: Fri, 11 Mar 2022 18:52:15 +0800	[thread overview]
Message-ID: <20220311105215.5408-1-lecopzer.chen@mediatek.com> (raw)
In-Reply-To: <YismXDtUZ2cPtVnN@shell.armlinux.org.uk>

> On Fri, Mar 11, 2022 at 12:08:52AM +0100, Linus Walleij wrote:
> > On Sun, Feb 27, 2022 at 2:48 PM Lecopzer Chen
> > <lecopzer.chen@mediatek.com> wrote:
> > 
> > > Since the framework of KASAN_VMALLOC is well-developed,
> > > It's easy to support for ARM that simply not to map shadow of VMALLOC
> > > area on kasan_init.
> > >
> > > Since the virtual address of vmalloc for Arm is also between
> > > MODULE_VADDR and 0x100000000 (ZONE_HIGHMEM), which means the shadow
> > > address has already included between KASAN_SHADOW_START and
> > > KASAN_SHADOW_END.
> > > Thus we need to change nothing for memory map of Arm.
> > >
> > > This can fix ARM_MODULE_PLTS with KASan, support KASan for higmem
> > > and provide the first step to support CONFIG_VMAP_STACK with Arm.
> > >
> > >
> > > Test on
> > > 1. Qemu with memory 2G and vmalloc=500M for 3G/1G mapping.
> > > 2. Qemu with memory 2G and vmalloc=500M for 3G/1G mapping + LPAE.
> > > 3. Qemu with memory 2G and vmalloc=500M for 2G/2G mapping.
> > >
> > > v3:
> > >     rebase on 5.17-rc5.
> > >     Add simple doc for "arm: kasan: support CONFIG_KASAN_VMALLOC"
> > >     Tweak commit message.
> > 
> > Ater testing this with my kernel-in-vmalloc patches and some hacks, I got
> > the kernel booting in the VMALLOC area with KASan enabled!
> > See:
> > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kernel-in-vmalloc-v5.17-rc1
> > 
> > That's a pretty serious stress test. So:
> > Tested-by: Linus Walleij <linus.walleij@linaro.org>
> > Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> > for the series.
> > 
> > I suppose you could put this into Russell's patch tracker, it's gonna be
> > for kernel v5.19 by now but why stress. It seems I can fix up
> > kernel-in-vmalloc on top and submit that for v5.19 as well.
> 
> Ard's series already adds vmap stack support (which we've been doing
> some last minute panic-debugging on to get it ready for this merge
> window), but the above description makes it sound like this series is
> a pre-requisit for that.
> 
> Is it? Will Ard's work cause further regressions because this series
> isn't merged.
> 
> Please clarify - and urgently, there is not much time left before the
> merge window opens.
> 

Sorry I didn't describe it clearly,

config VMAP_STACK
  default y
  bool "Use a virtually-mapped stack"
  depends on HAVE_ARCH_VMAP_STACK
  depends on !KASAN || KASAN_HW_TAGS || KASAN_VMALLOC

This means KASAN can support with VMAP_STACK=y



BRs,
Lecopzer

  reply	other threads:[~2022-03-11 10:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-27 13:47 [PATCH v3 0/2] arm: kasan: support CONFIG_KASAN_VMALLOC Lecopzer Chen
2022-02-27 13:47 ` Lecopzer Chen
2022-02-27 13:47 ` [PATCH v3 1/2] " Lecopzer Chen
2022-02-27 13:47   ` Lecopzer Chen
2022-03-11 10:34   ` Russell King (Oracle)
2022-03-11 10:34     ` Russell King (Oracle)
2022-03-11 10:47     ` Lecopzer Chen
2022-03-11 10:47       ` Lecopzer Chen
2022-02-27 13:47 ` [PATCH v3 2/2] arm: kconfig: fix MODULE_PLTS for KASAN with KASAN_VMALLOC Lecopzer Chen
2022-02-27 13:47   ` Lecopzer Chen
2022-03-10 23:08 ` [PATCH v3 0/2] arm: kasan: support CONFIG_KASAN_VMALLOC Linus Walleij
2022-03-10 23:08   ` Linus Walleij
2022-03-11 10:37   ` Russell King (Oracle)
2022-03-11 10:37     ` Russell King (Oracle)
2022-03-11 10:52     ` Lecopzer Chen [this message]
2022-03-11 10:52       ` Lecopzer Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220311105215.5408-1-lecopzer.chen@mediatek.com \
    --to=lecopzer.chen@mediatek.com \
    --cc=andreyknvl@gmail.com \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=dvyukov@google.com \
    --cc=geert+renesas@glider.be \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=lukas.bulwahn@gmail.com \
    --cc=mark.rutland@arm.com \
    --cc=masahiroy@kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=ryabinin.a.a@gmail.com \
    --cc=yj.chiang@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.