[DESIGN] Hardening page allocator against type confusion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux