lkml.org 
[lkml]   [2019]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v11 0/4] kasan: support backing vmalloc space with real shadow memory
From
Date


Le 31/10/2019 à 10:39, Daniel Axtens a écrit :
> Currently, vmalloc space is backed by the early shadow page. This
> means that kasan is incompatible with VMAP_STACK.
>
> This series provides a mechanism to back vmalloc space with real,
> dynamically allocated memory. I have only wired up x86, because that's
> the only currently supported arch I can work with easily, but it's
> very easy to wire up other architectures, and it appears that there is
> some work-in-progress code to do this on arm64 and s390.

There is also work for providing VMAP_STACK on powerpc32. There is a
series waiting to be merged at
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=145109

Christophe

>
> This has been discussed before in the context of VMAP_STACK:
> - https://bugzilla.kernel.org/show_bug.cgi?id=202009
> - https://lkml.org/lkml/2018/7/22/198
> - https://lkml.org/lkml/2019/7/19/822
>
> In terms of implementation details:
>
> Most mappings in vmalloc space are small, requiring less than a full
> page of shadow space. Allocating a full shadow page per mapping would
> therefore be wasteful. Furthermore, to ensure that different mappings
> use different shadow pages, mappings would have to be aligned to
> KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE.
>
> Instead, share backing space across multiple mappings. Allocate a
> backing page when a mapping in vmalloc space uses a particular page of
> the shadow region. This page can be shared by other vmalloc mappings
> later on.
>
> We hook in to the vmap infrastructure to lazily clean up unused shadow
> memory.
>
> Testing with test_vmalloc.sh on an x86 VM with 2 vCPUs shows that:
>
> - Turning on KASAN, inline instrumentation, without vmalloc, introuduces
> a 4.1x-4.2x slowdown in vmalloc operations.
>
> - Turning this on introduces the following slowdowns over KASAN:
> * ~1.76x slower single-threaded (test_vmalloc.sh performance)
> * ~2.18x slower when both cpus are performing operations
> simultaneously (test_vmalloc.sh sequential_test_order=1)
>
> This is unfortunate but given that this is a debug feature only, not
> the end of the world. The benchmarks are also a stress-test for the
> vmalloc subsystem: they're not indicative of an overall 2x slowdown!
>
>
> v1: https://lore.kernel.org/linux-mm/20190725055503.19507-1-dja@axtens.net/
> v2: https://lore.kernel.org/linux-mm/20190729142108.23343-1-dja@axtens.net/
> Address review comments:
> - Patch 1: use kasan_unpoison_shadow's built-in handling of
> ranges that do not align to a full shadow byte
> - Patch 3: prepopulate pgds rather than faulting things in
> v3: https://lore.kernel.org/linux-mm/20190731071550.31814-1-dja@axtens.net/
> Address comments from Mark Rutland:
> - kasan_populate_vmalloc is a better name
> - handle concurrency correctly
> - various nits and cleanups
> - relax module alignment in KASAN_VMALLOC case
> v4: https://lore.kernel.org/linux-mm/20190815001636.12235-1-dja@axtens.net/
> Changes to patch 1 only:
> - Integrate Mark's rework, thanks Mark!
> - handle the case where kasan_populate_shadow might fail
> - poision shadow on free, allowing the alloc path to just
> unpoision memory that it uses
> v5: https://lore.kernel.org/linux-mm/20190830003821.10737-1-dja@axtens.net/
> Address comments from Christophe Leroy:
> - Fix some issues with my descriptions in commit messages and docs
> - Dynamically free unused shadow pages by hooking into the vmap book-keeping
> - Split out the test into a separate patch
> - Optional patch to track the number of pages allocated
> - minor checkpatch cleanups
> v6: https://lore.kernel.org/linux-mm/20190902112028.23773-1-dja@axtens.net/
> Properly guard freeing pages in patch 1, drop debugging code.
> v7: https://lore.kernel.org/linux-mm/20190903145536.3390-1-dja@axtens.net/
> Add a TLB flush on freeing, thanks Mark Rutland.
> Explain more clearly how I think freeing is concurrency-safe.
> v8: https://lore.kernel.org/linux-mm/20191001065834.8880-1-dja@axtens.net/
> rename kasan_vmalloc/shadow_pages to kasan/vmalloc_shadow_pages
> v9: https://lore.kernel.org/linux-mm/20191017012506.28503-1-dja@axtens.net/
> (attempt to) address a number of review comments for patch 1.
> v10: https://lore.kernel.org/linux-mm/20191029042059.28541-1-dja@axtens.net/
> - rebase on linux-next, pulling in Vlad's new work on splitting the
> vmalloc locks.
> - after much discussion of barriers, document where I think they
> are needed and why. Thanks Mark and Andrey.
> - clean up some TLB flushing and checkpatch bits
> v11: Address review comments from Andrey and Vlad, drop patch 5, add benchmarking
> results.
>
> Daniel Axtens (4):
> kasan: support backing vmalloc space with real shadow memory
> kasan: add test for vmalloc
> fork: support VMAP_STACK with KASAN_VMALLOC
> x86/kasan: support KASAN_VMALLOC
>
> Documentation/dev-tools/kasan.rst | 63 ++++++++
> arch/Kconfig | 9 +-
> arch/x86/Kconfig | 1 +
> arch/x86/mm/kasan_init_64.c | 61 ++++++++
> include/linux/kasan.h | 31 ++++
> include/linux/moduleloader.h | 2 +-
> include/linux/vmalloc.h | 12 ++
> kernel/fork.c | 4 +
> lib/Kconfig.kasan | 16 +++
> lib/test_kasan.c | 26 ++++
> mm/kasan/common.c | 231 ++++++++++++++++++++++++++++++
> mm/kasan/generic_report.c | 3 +
> mm/kasan/kasan.h | 1 +
> mm/vmalloc.c | 53 +++++--
> 14 files changed, 500 insertions(+), 13 deletions(-)
>

\
 
 \ /
  Last update: 2019-12-02 09:08    [W:0.135 / U:10.528 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site