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? -- Kees Cook
