Nope. I don't know why just checking the tags during speculation wouldn't stop Spectre V1, at least for cross-type accesses? I mean, it's not that simple because your program won't crash if speculation has mismatched tags. Which means you can try as many times as you want until you get lucky. But that's certainly not a "completely novel mitigation", so I'm sure I'm missing something obvious.

Perhaps the real problem is that you can use speculation to scan large amounts of memory for matching tags, some of which would be different types, so you need something to handle that?

(talking out of my butt here)

That post[^1] linked by saagarjha above is talking about the case where the typed allocator (plus the layout of kernel memory, and whatever constraints on pointer arithmetic in the kernel) makes Spectre less useful. MTE itself isn't relevant to mitigating Spectre, but putting constraints on how the addresses of certain loads in the kernel are computed makes Spectre less useful.

Remember that Spectre V1 is about causing the kernel to [incorrectly and] speculatively perform a load, and then trying to leak the loaded value by measuring the state of the cache. You might reasonably want to try this since MTE tags are stored in kernel memory.

But if the set of all possible target addresses for relevant loads on a path subject to influence by userspace can be constrained to a particular memory region, you [presumably] cannot trivially use Spectre V1 to leak values from a different region.

Also, see this[^2] paper referenced in the article.

[^1]: https://mastodon.online/@ezhes_/115175838087995856

[^2]: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=983...

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.