On Mon, 22 Jan 2024 05:49:29 dvyukov@xxxxxxxxxx wrote: >> >> From: Li Zhe <lizhe.67@xxxxxxxxxxxxx> >> >> 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. > >> 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(-)
