Re: [RFC 0/2] kasan: introduce mem track feature

From: Marco Elver <elver@google.com>
To: lizhe.67@bytedance.com
Cc: ryabinin.a.a@gmail.com, glider@google.com, andreyknvl@gmail.com,
	 dvyukov@google.com, vincenzo.frascino@arm.com,
	akpm@linux-foundation.org,  kasan-dev@googlegroups.com,
	linux-mm@kvack.org, lizefan.x@bytedance.com
Subject: Re: [RFC 0/2] kasan: introduce mem track feature
Date: Thu, 18 Jan 2024 14:28:00 +0100	[thread overview]
Message-ID: <CANpmjNOnxvGNtApe50vyAZLmoNbEpLeMiKHXRuRABkn6nhEQWA@mail.gmail.com> (raw)
In-Reply-To: <20240118124109.37324-1-lizhe.67@bytedance.com>

On Thu, 18 Jan 2024 at 13:41, lizhe.67 via kasan-dev
<kasan-dev@googlegroups.com> wrote:
>
> From: Li Zhe <lizhe.67@bytedance.com>
>
> 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.

> 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.