You’re on the right track, I think. The mastodon link posted in a sibling comment within a minute of yours provides more details:

It sounds like the kernel’s allocations may only use one tag(?). So if you get in there, jackpot right? No tags to deal with.

So they’re using special compiler flags to limit all offsets to less than 4 GB. Then they placed different parts of the kernel far apart in address space with a 4 GB unmapped zone.

So if you can put your own pointer somewhere that’s exploitable in allocated kernel memory, there is no way for it to point to any other “part” of kernel memory. Only within that one “area”.

Presumably this would mean that exploiting a problem in the graphics drivers would not make it possible to provide a pointer pointing to the Secure Enclave interface code. Or something like that.

I’m not 100% on if I’m understanding it correctly.

Kind of, but they don't just use one tag, they use all the tags just as userspace would. You throw all the allocations with the same type into a <4GB region and tag it, then make sure that pointer arithmetic stays within that region.

> It sounds like the kernel’s allocations may only use one tag

What about the blogpost suggested this?

" ... always-on memory safety protection for our key attack surfaces including the kernel ..."

" ... always-on memory-safety protection covering key attack surfaces — including the kernel and over 70 userland processes — built on the Enhanced Memory Tagging Extension (EMTE) and supported by secure typed allocators and tag confidentiality protections ... "

Suggests to me that the kernel allocator uses a similar tagging policy as the userspace allocators do.