On 9/22/22 23:49, Kees Cook wrote:

On Thu, Sep 22, 2022 at 11:05:47PM +0200, Vlastimil Babka wrote:

quoted

On 9/22/22 17:55, Kees Cook wrote:

quoted

On Thu, Sep 22, 2022 at 09:10:56AM +0200, Christian König wrote:
[...]

quoted

So when this patch set is about to clean up this use case it should probably
also take care to remove ksize() or at least limit it so that it won't be
used for this use case in the future.

Yeah, my goal would be to eliminate ksize(), and it seems possible if
other cases are satisfied with tracking their allocation sizes directly.

I think we could leave ksize() to determine the size without a need for
external tracking, but from now on forbid callers from using that hint to
overflow the allocation size they actually requested? Once we remove the
kasan/kfence hooks in ksize() that make the current kinds of usage possible,
we should be able to catch any offenders of the new semantics that would appear?

That's correct. I spent the morning working my way through the rest of
the ksize() users I didn't clean up yesterday, and in several places I
just swapped in __ksize(). But that wouldn't even be needed if we just
removed the kasan unpoisoning from ksize(), etc.

I am tempted to leave it __ksize(), though, just to reinforce that it's
not supposed to be used "normally". What do you think?

Sounds good. Note in linux-next there's now a series in slab.git planned for
6.1 that moves __ksize() declaration to mm/slab.h to make it more private.
But we don't want random users outside mm and related kasan/kfence
subsystems to include mm/slab.h, so we'll have to expose it again instead of
ksize().