[PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

[js1304]

From: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>

Hello, all.

This is an attempt to recude memory consumption of KASAN. Please see
following description to get the more information.

1. What is per-page shadow memory

This patch introduces infrastructure to support per-page shadow memory.
Per-page shadow memory is the same with original shadow memory except
the granualarity. It's one byte shows the shadow value for the page.
The purpose of introducing this new shadow memory is to save memory
consumption.

2. Problem of current approach

Until now, KASAN needs shadow memory for all the range of the memory
so the amount of statically allocated memory is so large. It causes
the problem that KASAN cannot run on the system with hard memory
constraint. Even if KASAN can run, large memory consumption due to
KASAN changes behaviour of the workload so we cannot validate
the moment that we want to check.

3. How does this patch fix the problem

This patch tries to fix the problem by reducing memory consumption for
the shadow memory. There are two observations.

1) Type of memory usage can be distinguished well.
2) Shadow memory is manipulated/checked in byte unit only for slab,
kernel stack and global variable. Shadow memory for other usecases
just show KASAN_FREE_PAGE or 0 (means valid) in page unit.

With these two observations, I think an optimized way to support
KASAN feature.

1) Introduces per-page shadow that cover all the memory
2) Checks validity of the access through per-page shadow except
that checking object is a slab, kernel stack, global variable
3) For those byte accessible types of object, allocate/map original
shadow by on-demand and checks validity of the access through
original shadow

Instead original shadow statically consumes 1/8 bytes of the amount of
total memory, per-page shadow statically consumes 1/PAGE_SIZE bytes of it.
Extra memory is required for a slab, kernel stack and global variable by
on-demand in runtime, however, it would not be larger than before.

4. Result

Following is the result of the memory consumption on my QEMU system.
'runtime' shows the maximum memory usage for on-demand shadow allocation
during the kernel build workload.

base vs patched

MemTotal: 858 MB vs 987 MB
runtime: 0 MB vs 30MB
Net Available: 858 MB vs 957 MB

For 4096 MB QEMU system

MemTotal: 3477 MB vs 4000 MB
runtime: 0 MB vs 50MB

base vs patched (2048 MB QEMU system)
204 s vs 224 s
Net Available: 3477 MB vs 3950 MB

Thanks.

Joonsoo Kim (11):
  mm/kasan: rename XXX_is_zero to XXX_is_nonzero
  mm/kasan: don't fetch the next shadow value speculartively
  mm/kasan: handle unaligned end address in zero_pte_populate
  mm/kasan: extend kasan_populate_zero_shadow()
  mm/kasan: introduce per-page shadow memory infrastructure
  mm/kasan: mark/unmark the target range that is for original shadow
    memory
  x86/kasan: use per-page shadow memory
  mm/kasan: support on-demand shadow allocation/mapping
  x86/kasan: support on-demand shadow mapping
  mm/kasan: support dynamic shadow memory free
  mm/kasan: change the order of shadow memory check

 arch/arm64/mm/kasan_init.c       |  17 +-
 arch/x86/include/asm/kasan.h     |   8 +
 arch/x86/include/asm/processor.h |   4 +
 arch/x86/kernel/cpu/common.c     |   4 +-
 arch/x86/kernel/setup_percpu.c   |   2 +
 arch/x86/mm/kasan_init_64.c      | 191 ++++++++++++--
 include/linux/kasan.h            |  71 ++++-
 kernel/fork.c                    |   7 +
 mm/kasan/kasan.c                 | 555 +++++++++++++++++++++++++++++++++------
 mm/kasan/kasan.h                 |  22 +-
 mm/kasan/kasan_init.c            | 158 ++++++++---
 mm/kasan/report.c                |  28 ++
 mm/page_alloc.c                  |  10 +
 mm/slab.c                        |   9 +
 mm/slab_common.c                 |  11 +-
 mm/slub.c                        |   8 +
 16 files changed, 957 insertions(+), 148 deletions(-)

-- 
2.7.4