On Thu, 18 Jan 2024 14:28:00, elver@xxxxxxxxxx wrote:
>> 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.
>
>Note: "track" is already an overloaded word with KASAN, meaning some
>allocation/free stack trace info + CPU id, task etc.
Thanks for the reminder, I will change it to another name in the v2 patch.
>> 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.
>
>It took me several readings to understand what problem you're actually
>trying to solve. AFAIK, you're trying to add custom poison/unpoison
>functions.
>
>From what I can tell this is duplicating functionality: it is
>perfectly legal to poison and unpoison memory while it is already
>allocated. I think it used to be the case the kasan_poison/unpoison()
>were API functions, but since tag-based KASAN modes this was changed
>to hide the complexity here.
>
>But you could simply expose a simpler variant of kasan_{un,}poison,
>e.g. kasan_poison/unpoison_custom(). You'd have to introduce another
>type (see where KASAN_PAGE_FREE, KASAN_SLAB_FREE is defined) to
>distinguish this custom type from other poisoned memory.
>
>Obviously it would be invalid to kasan_poison_custom() memory that is
>already poisoned, because that would discard the pre-existing poison
>type.
>
>With that design, I believe it would also work for the inline version
>of KASAN and not just outline version.
Thank you for your review!
Yes I am trying to add custom poison/unpoison functions which can monitor
memory in a fine-grained manner, and not affect the original functionality
of kasan. 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/unpoison() can do what I want.
