From: David Gow <davidgow@google.com>
To: Vincent Whitchurch <vincent.whitchurch@axis.com>,
Johannes Berg <johannes@sipsolutions.net>,
Patricia Alfonso <trishalfonso@google.com>,
Jeff Dike <jdike@addtoit.com>,
Richard Weinberger <richard@nod.at>,
Anton Ivanov <anton.ivanov@cambridgegreys.com>,
Dmitry Vyukov <dvyukov@google.com>,
Brendan Higgins <brendanhiggins@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andrey Konovalov <andreyknvl@gmail.com>,
Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: kasan-dev <kasan-dev@googlegroups.com>,
linux-um <linux-um@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Daniel Latypov <dlatypov@google.com>,
Linux Memory Management List <linux-mm@kvack.org>,
KUnit Development <kunit-dev@googlegroups.com>
Subject: Re: [PATCH v3 2/2] UML: add support for KASAN under x86_64
Date: Thu, 30 Jun 2022 16:11:46 +0800 [thread overview]
Message-ID: <CABVgOS=0PmF5k8RcP2Q3JNkMXK4Pd6ZLVGgCT9Ff+t9Dt_wA=w@mail.gmail.com> (raw)
In-Reply-To: <20220630074757.2739000-2-davidgow@google.com>
On Thu, Jun 30, 2022 at 3:48 PM David Gow <davidgow@google.com> wrote:
>
> From: Patricia Alfonso <trishalfonso@google.com>
>
> Make KASAN run on User Mode Linux on x86_64.
>
> The UML-specific KASAN initializer uses mmap to map the ~16TB of shadow
> memory to the location defined by KASAN_SHADOW_OFFSET. kasan_init()
> utilizes constructors to initialize KASAN before main().
>
> The location of the KASAN shadow memory, starting at
> KASAN_SHADOW_OFFSET, can be configured using the KASAN_SHADOW_OFFSET
> option. The default location of this offset is 0x100000000000, which
> keeps it out-of-the-way even on UML setups with more "physical" memory.
>
> For low-memory setups, 0x7fff8000 can be used instead, which fits in an
> immediate and is therefore faster, as suggested by Dmitry Vyukov. There
> is usually enough free space at this location; however, it is a config
> option so that it can be easily changed if needed.
>
> Note that, unlike KASAN on other architectures, vmalloc allocations
> still use the shadow memory allocated upfront, rather than allocating
> and free-ing it per-vmalloc allocation.
>
> If another architecture chooses to go down the same path, we should
> replace the checks for CONFIG_UML with something more generic, such
> as:
> - A CONFIG_KASAN_NO_SHADOW_ALLOC option, which architectures could set
> - or, a way of having architecture-specific versions of these vmalloc
> and module shadow memory allocation options.
>
> Also note that, while UML supports both KASAN in inline mode
> (CONFIG_KASAN_INLINE) and static linking (CONFIG_STATIC_LINK), it does
> not support both at the same time.
>
> Signed-off-by: Patricia Alfonso <trishalfonso@google.com>
> Co-developed-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
> Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
> Signed-off-by: David Gow <davidgow@google.com>
> Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> This is v3 of the KASAN/UML port. It should be ready to go.
>
> Note that this will fail to build if UML is linked statically due to:
> https://lore.kernel.org/all/20220526185402.955870-1-davidgow@google.com/
>
>
> Changes since v2:
> https://lore.kernel.org/lkml/20220527185600.1236769-2-davidgow@google.com/
> - Don't define CONFIG_KASAN in USER_CFLAGS, given we dont' use it.
> (Thanks Johannes)
> - Update patch descriptions and comments given we allocate shadow memory based
> on the size of the virtual address space, not the "physical" memory
> used by UML.
> - This was changed between the original RFC and v1, with
> KASAN_SHADOW_SIZE's definition being updated.
> - References to UML using 18TB of space and the shadow memory taking
> 2.25TB were updated. (Thanks Johannes)
> - A mention of physical memory in a comment was updated. (Thanks
> Andrey)
> - Move some discussion of how the vmalloc() handling could be made more
> generic from a comment to the commit description. (Thanks Andrey)
>
> Changes since RFC v3:
> https://lore.kernel.org/all/20220526010111.755166-1-davidgow@google.com/
> - No longer print "KernelAddressSanitizer initialized" (Johannes)
> - Document the reason for the CONFIG_UML checks in shadow.c (Dmitry)
> - Support static builds via kasan_arch_is_ready() (Dmitry)
> - Get rid of a redundant call to kasam_mem_to_shadow() (Dmitry)
> - Use PAGE_ALIGN and the new PAGE_ALIGN_DOWN macros (Dmitry)
> - Reinstate missing arch/um/include/asm/kasan.h file (Johannes)
>
> Changes since v1:
> https://lore.kernel.org/all/20200226004608.8128-1-trishalfonso@google.com/
> - Include several fixes from Vincent Whitchurch:
> https://lore.kernel.org/all/20220525111756.GA15955@axis.com/
> - Support for KASAN_VMALLOC, by changing the way
> kasan_{populate,release}_vmalloc work to update existing shadow
> memory, rather than allocating anything new.
> - A similar fix for modules' shadow memory.
> - Support for KASAN_STACK
> - This requires the bugfix here:
> https://lore.kernel.org/lkml/20220523140403.2361040-1-vincent.whitchurch@axis.com/
> - Plus a couple of files excluded from KASAN.
> - Revert the default shadow offset to 0x100000000000
> - This was breaking when mem=1G for me, at least.
> - A few minor fixes to linker sections and scripts.
> - I've added one to dyn.lds.S on top of the ones Vincent added.
>
> ---
<... snip ...>
> diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
> index a4f07de21771..7a7fc76e99a8 100644
> --- a/mm/kasan/shadow.c
> +++ b/mm/kasan/shadow.c
> @@ -295,9 +295,22 @@ int kasan_populate_vmalloc(unsigned long addr, unsigned long size)
> return 0;
>
> shadow_start = (unsigned long)kasan_mem_to_shadow((void *)addr);
> - shadow_start = ALIGN_DOWN(shadow_start, PAGE_SIZE);
> shadow_end = (unsigned long)kasan_mem_to_shadow((void *)addr + size);
> - shadow_end = ALIGN(shadow_end, PAGE_SIZE);
> +
> + /*
> + * User Mode Linux maps enough shadow memory for all of virtual memory
> + * at boot, so doesn't need to allocate more on vmalloc, just clear it.
> + *
> + * The remaining CONFIG_UML checks in this file exist for the same
> + * reason.
> + */
Whoops: these lines had tabs converted to spaces when I reformatted
them. I've sent out v4 which actually passes checkpatch:
https://lore.kernel.org/lkml/20220630080834.2742777-2-davidgow@google.com/
Sorry for the spam!
-- David
prev parent reply other threads:[~2022-06-30 8:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-30 7:47 [PATCH v3 1/2] mm: Add PAGE_ALIGN_DOWN macro David Gow
2022-06-30 7:47 ` [PATCH v3 2/2] UML: add support for KASAN under x86_64 David Gow
2022-06-30 8:11 ` David Gow [this message]
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='CABVgOS=0PmF5k8RcP2Q3JNkMXK4Pd6ZLVGgCT9Ff+t9Dt_wA=w@mail.gmail.com' \
--to=davidgow@google.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=anton.ivanov@cambridgegreys.com \
--cc=brendanhiggins@google.com \
--cc=dlatypov@google.com \
--cc=dvyukov@google.com \
--cc=jdike@addtoit.com \
--cc=johannes@sipsolutions.net \
--cc=kasan-dev@googlegroups.com \
--cc=kunit-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-um@lists.infradead.org \
--cc=richard@nod.at \
--cc=ryabinin.a.a@gmail.com \
--cc=trishalfonso@google.com \
--cc=vincent.whitchurch@axis.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).