Re: [DESIGN] Hardening page allocator against type confusion

[Vlastimil Babka <vbabka@suse.cz>]

On 9/25/24 21:46, Matthew Wilcox wrote:
> Kees and I had a fun discussion at Plumbers.
> 
> We're trying to harden against type confusion, where we think we have
> a pointer to one thing, but it turns out to be a pointer to a different
> thing.  There's various ways this can be harmful, which Kees has laid out
> before when adding slab buckets.  eg see https://lwn.net/Articles/978976/
> 
> Not all allocations come from slab though.  If we free a slab object
> and the slab it was in gets freed back to the page allocator, it can
> turn into almost anything else _quickly_ as the page allocator fronts
> the buddy allocator with a stack of recently-freed pages (called PCP,
> not to be confused with percpu memory), so if the attacker can arrange
> for a page table allocation to come in soon after a slab free, it is
> very likely to be the memory they have access to.
> 
> My proposal is that we resolve this "type confusion" by having separate
> PCP lists for different types of pages.  We'll need to have this for
> memdescs anyway, so this is just shifting some of the work left.
> 
> We'd reduce the exploitability of type confusion by using a per-CPU,
> per-type stack of recently used pages.  To turn a slab page into a page
> table page, the attacker would have to cause a dozen slabs to be freed on
> this CPU, pushing this one into the buddy allocator.  Then they'd have
> to cause the allocating task to empty its stack of page table pages,
> causing the attackable slab to be pulled from the buddy.  It's still
> possible, but it's harder.
> 
> Harder enough?  I don't know, hence this email.  We can get into the
> API design (and then the implementation design) if we have agreement
> that this is the right approach to be taking.

Not a security expert but I doubt it's harder enough?

I thought the robust mitigation here was SLAB_VIRTUAL