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?