From: Lecopzer Chen <lecopzer.chen@mediatek.com>
To: <ardb@kernel.org>
Cc: <akpm@linux-foundation.org>, <andreyknvl@google.com>,
<aryabinin@virtuozzo.com>, <broonie@kernel.org>,
<catalin.marinas@arm.com>, <dan.j.williams@intel.com>,
<dvyukov@google.com>, <glider@google.com>,
<gustavoars@kernel.org>, <kasan-dev@googlegroups.com>,
<lecopzer.chen@mediatek.com>, <lecopzer@gmail.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>,
<linux-mediatek@lists.infradead.org>, <linux-mm@kvack.org>,
<linux@roeck-us.net>, <robin.murphy@arm.com>, <rppt@kernel.org>,
<tyhicks@linux.microsoft.com>, <vincenzo.frascino@arm.com>,
<will@kernel.org>, <yj.chiang@mediatek.com>
Subject: Re: [PATCH v2 1/4] arm64: kasan: don't populate vmalloc area for CONFIG_KASAN_VMALLOC
Date: Thu, 4 Feb 2021 14:21:28 +0800 [thread overview]
Message-ID: <20210204062128.27692-1-lecopzer.chen@mediatek.com> (raw)
In-Reply-To: <CAMj1kXEMOeCZTvNqPPk-uL5iA7hx7SFPwkq3Oz3yYefn=tVnPQ@mail.gmail.com>
> On Sat, 9 Jan 2021 at 11:33, Lecopzer Chen <lecopzer@gmail.com> wrote:
> >
> > Linux support KAsan for VMALLOC since commit 3c5c3cfb9ef4da9
> > ("kasan: support backing vmalloc space with real shadow memory")
> >
> > Like how the MODULES_VADDR does now, just not to early populate
> > the VMALLOC_START between VMALLOC_END.
> > similarly, the kernel code mapping is now in the VMALLOC area and
> > should keep these area populated.
> >
> > Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
>
>
> This commit log text is a bit hard to follow. You are saying that the
> vmalloc region is *not* backed with zero shadow or any default mapping
> at all, right, and everything gets allocated on demand, just like is
> the case for modules?
It's much more like:
before:
MODULE_VADDR: no mapping, no zoreo shadow at init
VMALLOC_VADDR: backed with zero shadow at init
after:
MODULE_VADDR: no mapping, no zoreo shadow at init
VMALLOC_VADDR: no mapping, no zoreo shadow at init
So it should be both "not backed with zero shadow" and
"not any mapping and everything gets allocated on demand".
And the "not backed with zero shadow" is like a subset of "not any mapping ...".
Is that being more clear if the commit revises to:
----------------------
Like how the MODULES_VADDR does now, just not to early populate
the VMALLOC_START between VMALLOC_END.
Before:
MODULE_VADDR: no mapping, no zoreo shadow at init
VMALLOC_VADDR: backed with zero shadow at init
After:
VMALLOC_VADDR: no mapping, no zoreo shadow at init
Thus the mapping will get allocate on demand by the core function
of KASAN vmalloc.
similarly, the kernel code mapping is now in the VMALLOC area and
should keep these area populated.
--------------------
Or would you have any suggestion?
Thanks a lot for your review!
BRs,
Lecopzer
next prev parent reply other threads:[~2021-02-04 6:22 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-09 10:32 [PATCH v2 0/4] arm64: kasan: support CONFIG_KASAN_VMALLOC Lecopzer Chen
2021-01-09 10:32 ` [PATCH v2 1/4] arm64: kasan: don't populate vmalloc area for CONFIG_KASAN_VMALLOC Lecopzer Chen
2021-02-03 18:37 ` Ard Biesheuvel
2021-02-04 6:21 ` Lecopzer Chen [this message]
2021-02-04 12:45 ` Will Deacon
2021-02-04 14:46 ` Lecopzer Chen
2021-02-04 15:01 ` Will Deacon
2021-02-04 16:37 ` Lecopzer Chen
2021-02-05 17:18 ` Will Deacon
2021-02-05 17:30 ` Andrey Konovalov
2021-02-05 17:43 ` Will Deacon
2021-02-05 20:50 ` Andrey Konovalov
2021-02-05 18:10 ` Lecopzer Chen
2021-01-09 10:32 ` [PATCH v2 2/4] arm64: kasan: abstract _text and _end to KERNEL_START/END Lecopzer Chen
2021-02-04 12:46 ` Will Deacon
2021-02-04 14:51 ` Lecopzer Chen
2021-02-04 14:55 ` Will Deacon
2021-02-04 16:06 ` Lecopzer Chen
2021-02-05 17:02 ` Will Deacon
2021-01-09 10:32 ` [PATCH v2 3/4] arm64: Kconfig: support CONFIG_KASAN_VMALLOC Lecopzer Chen
2021-01-09 10:32 ` [PATCH v2 4/4] arm64: kaslr: support randomized module area with KASAN_VMALLOC Lecopzer Chen
2021-01-27 23:04 ` Will Deacon
2021-01-28 8:53 ` Lecopzer Chen
2021-01-28 20:26 ` Will Deacon
2021-01-21 10:19 ` [PATCH v2 0/4] arm64: kasan: support CONFIG_KASAN_VMALLOC Lecopzer Chen
2021-01-21 17:44 ` Andrey Konovalov
2021-01-22 19:05 ` Will Deacon
2021-02-03 18:31 ` Ard Biesheuvel
2021-02-04 12:49 ` Will Deacon
2021-02-04 15:53 ` Lecopzer Chen
2021-02-04 17:57 ` Will Deacon
2021-02-04 18:41 ` 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=20210204062128.27692-1-lecopzer.chen@mediatek.com \
--to=lecopzer.chen@mediatek.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@google.com \
--cc=ardb@kernel.org \
--cc=aryabinin@virtuozzo.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dan.j.williams@intel.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=gustavoars@kernel.org \
--cc=kasan-dev@googlegroups.com \
--cc=lecopzer@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=linux@roeck-us.net \
--cc=robin.murphy@arm.com \
--cc=rppt@kernel.org \
--cc=tyhicks@linux.microsoft.com \
--cc=vincenzo.frascino@arm.com \
--cc=will@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).