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