grsecurity.net/how_autoslab_… nice article here. We're shipping, in iOS 15 and aligned releases, a protection with a very similar spirit. we call it kalloc_type(). Our impl has different characteristics, e.g. XNU has zone sequestering, so cross-zone attacks isn't a thing.
2
9
4
61
Based on the API name, I assume this isn't used for everything? It's not clear from the current blog (since the purpose was the security eval, not debugging or other aspects), but we get some nice properties out of having AUTOSLAB applied to everything:
grsecurity @grsecurity
27 Jul 2021
Extending on what AUTOSLAB already had earlier, the next beta will be able to turn arbitrary addresses instantly into something like: autoslab_const_M_main_P_init_main_1100_27_1100_27_S_6848_A_64_n_1.task_struct.wake_entry.llist.next+0x38/0x1ac0 without any sl[a|u]b debugging
2
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
Replying to @pedantcoder @spendergrsec
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).

Aug 12, 2021 · 8:18 PM UTC

1
1
Replying to @paxteam @spendergrsec
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
more replies