On Mon, 22 Jan 2024 08:03:17, 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. > >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(-)
