On 9/22/22 23:49, Kees Cook wrote:
On Thu, Sep 22, 2022 at 11:05:47PM +0200, Vlastimil Babka wrote:
On 9/22/22 17:55, Kees Cook wrote:
On Thu, Sep 22, 2022 at 09:10:56AM +0200, Christian König wrote: [...]
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().