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

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?

-- 
Kees Cook