On Tue, Oct 6, 2020 at 4:09 AM Kees Cook <keescook@xxxxxxxxxxxx> wrote: > On Tue, Oct 06, 2020 at 01:44:14AM +0100, Matthew Wilcox wrote: > > On Tue, Oct 06, 2020 at 12:56:33AM +0200, Jann Horn wrote: > > > It seems to me like, if you want to make UAF exploitation harder at > > > the heap allocator layer, you could do somewhat more effective things > > > with a probably much smaller performance budget. Things like > > > preventing the reallocation of virtual kernel addresses with different > > > types, such that an attacker can only replace a UAF object with > > > another object of the same type. (That is not an idea I like very much > > > either, but I would like it more than this proposal.) (E.g. some > > > browsers implement things along those lines, I believe.) > > > > The slab allocator already has that functionality. We call it > > TYPESAFE_BY_RCU, but if forcing that on by default would enhance security > > by a measurable amount, it wouldn't be a terribly hard sell ... > > Isn't the "easy" version of this already controlled by slab_merge? (i.e. > do not share same-sized/flagged kmem_caches between different caches) Yes, but slab_merge still normally frees slab pages to the page allocator. > The large trouble are the kmalloc caches, which don't have types > associated with them. Having implicit kmem caches based on the type > being allocated there would need some pretty extensive plumbing, I > think? Well, a bit of plumbing, at least. You'd need to teach the compiler frontend to grab type names from sizeof() and stuff that type information somewhere, e.g. by generating an extra function argument referring to the type, or something like that. Could be as simple as a reference to a bss section variable that encodes the type in the name, and the linker already has the logic to automatically deduplicate those across compilation units - that way, on the compiler side, a pure frontend plugin might do the job?
