Or Solaris SPARC ADI memory allocator,

https://docs.oracle.com/cd/E88353_01/html/E37843/malloc-3c.h...

Yeah that work is way more impressive.

I like how they demonstrated exactly how it impacts known exploits for example

Yes, but it also means you need an Apple device, and hence a locked down system. You also need to take all of Apple's privacy claims at face value. No thanks.

> They don’t prevent the attacker from pivoting a memory safety bug to remote execution.

I'm confused. Isn't this potentially preventing some classes of memory-safety bugs?

> I think what Apple is doing with typed allocations is much more principled and they have data to prove it in their blog posts

This is one of the things that hardened malloc is doing (and is part of the post). Newer pixels are shipping with MTE support and graphene's malloc leverages MTE as much as possible.

There might be processes that have high privileges, but don't need high performance, for example: sudo utility, new USB device detection daemon, bluetooth communication daemon.

Also idea described in Apple's article (never reuse allocated addresses for other types) cannot be easily implemented for any allocator. Consider a memory pipe (circular buffer), where one process pushes messages and another reads them. How do you implement Apple-style memory safety here? One of the ideas is of course to map the buffer multiple times, so that every allocation returns a new virtual address, but how many syscalls you will need for that and how badly that would impact performance.