We typically do not comment on future roadmaps so I won’t go in details. But yes unlike autoslab we rely on manual adoption and it isn’t thorough yet, and covers zones (~= sub-page) for now.
We are indeed type based which gives us precise free sites (the free site pins types)
3
2
3
re: sequestering, it's 2 scalability problems: perf impact of small pages (e.g., linux/kmalloc uses the lowmem map with 2M/1G pages on amd64) and available address space (think 100k autoslabs and months of uptime on a busy server).
1
1
you assume we used 100k zones ;)
we randomize type-to-zone mappings each boot, sequestering combined with precise free sites allows us to tune the balance between perf and security.
iDevices have even less RAM, and run in such trouble you mention even faster than a busy server
1
the 100k was the autoslab number and i'm pretty sure manual conversion or the whole sequestering idea wouldn't scale there :). re free sites, are you saying (if you can :) that objects from the same allocation site(s) can end up in different zones (some sequestered, some not)?
1
No. I say that we group types into buckets to diminish the number of zones (slabs). But in general a free site can only free to a single zone. If an attacker tries to pass a pointer from bucket slab you panic. This rigidity makes up for the bucketting we do
1
To exploit a vuln you need to do it with the types your bucket shares as a result. That’s it. and that bucketing is random.
1
so does it mean that once a physical page is allocated to a (sequestered) zone, it'll never be freed, even if all objects in that zone get freed? 'cos i don't see how else you can guarantee that there's no cross-cache attack possible.
1
VA is not reused and we zero pages on population so you can’t ever see data from a physical page from a previous life.
2
so you do free the backing page and allow it to be reallocated to another zone later. then cross-cache UAF exploitation is still possible, right?
1
if the page gets reallocated to the same zone some time later then the dangling ptr (VA) becomes 'valid' again (no page fault on deref), and can now point into an object of a different type (since more than one type shares the given zone if i got you right).
Aug 13, 2021 · 9:01 PM UTC
1
1

