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

[Dmitry Vyukov <dvyukov@google.com>]

On Mon, 22 Jan 2024 at 07:26, <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.
>
> Thank you for your review!
>
> For example, for a 100-byte variable, I may only want to monitor certain
> two bytes (byte 3 and 4) in it. According to my understanding,
> kasan_poison/unpoison() can not detect the middle bytes individually. So I
> don't think function kasan_poison_range() can do what I want.

That's something to note in the description/comments.

How many ranges do you intend to protect this way?
If that's not too many, then a better option would be to poison these
ranges normally and store ranges that a thread can access currently on
a side.
This will give both 1-byte precision, filtering for reads/writes
separately and better diagnostics.


> >> 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(-)