On Mon, 22 Jan 2024 at 07:26, <lizhe.67@xxxxxxxxxxxxx> 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. > >> 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(-)
