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

[lizhe.67@bytedance.com]

On Mon, 22 Jan 2024 08:03:17, dvyukov@google.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.

OK I will find a better method to solve this problem.

Thank you!
>
>> >> 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(-)