On Thu, 18 Jan 2024 at 13:41, <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. > 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(-) > > -- > 2.20.1 >
