Re: [RFC 0/2] kasan: introduce mem track feature

[Dmitry Vyukov <dvyukov@google.com>]

On Thu, 18 Jan 2024 at 13:41, <lizhe.67@bytedance.com> wrote:
>
> From: Li Zhe <lizhe.67@bytedance.com>
>
> 1. Problem
> ==========
> KASAN is a tools for detecting memory bugs like out-of-bounds and
> use-after-free. In Generic KASAN mode, it use shadow memory to record
> the accessible information of the memory. After we allocate a memory
> from kernel, the shadow memory corresponding to this memory will be
> marked as accessible.
> In our daily development, memory problems often occur. If a task
> accidentally modifies memory that does not belong to itself but has
> been allocated, some strange phenomena may occur. This kind of problem
> brings a lot of trouble to our development, and unluckily, this kind of
> problem cannot be captured by KASAN. This is because as long as the
> accessible information in shadow memory shows that the corresponding
> memory can be accessed, KASAN considers the memory access to be legal.
>
> 2. Solution
> ===========
> We solve this problem by introducing mem track feature base on KASAN
> with Generic KASAN mode. In the current kernel implementation, we use
> bits 0-2 of each shadow memory byte to store how many bytes in the 8
> byte memory corresponding to the shadow memory byte can be accessed.
> When a 8-byte-memory is inaccessible, the highest bit of its
> corresponding shadow memory value is 1. Therefore, the key idea is that
> we can use the currently unused four bits 3-6 in the shadow memory to
> record relevant track information. Which means, we can use one bit to
> track 2 bytes of memory. If the track bit of the shadow mem corresponding
> to a certain memory is 1, it means that the corresponding 2-byte memory
> is tracked. By adding this check logic to KASAN's callback function, we
> can use KASAN's ability to capture allocated memory corruption.
>
> 3. Simple usage
> ===========
> The first step is to mark the memory as tracked after the allocation is
> completed.
> The second step is to remove the tracked mark of the memory before the
> legal access process and re-mark the memory as tracked after finishing
> the legal access process.

KASAN already has a notion of memory poisoning/unpoisoning.
See kasan_unpoison_range function. We don't export kasan_poison_range,
but if you do local debuggng, you can export it locally.

> The first patch completes the implementation of the mem track, and the
> second patch provides an interface for using this facility, as well as
> a testcase for the interface.
>
> Li Zhe (2):
>   kasan: introduce mem track feature base on kasan
>   kasan: add mem track interface and its test cases
>
>  include/linux/kasan.h        |   5 +
>  lib/Kconfig.kasan            |   9 +
>  mm/kasan/generic.c           | 437 +++++++++++++++++++++++++++++++++--
>  mm/kasan/kasan_test_module.c |  26 +++
>  mm/kasan/report_generic.c    |   6 +
>  5 files changed, 467 insertions(+), 16 deletions(-)
>
> --
> 2.20.1
>