>The presence of EMTE leaves Spectre V1 as one of the last avenues available to attackers to help guide their attacks, so we designed a completely novel mitigation that limits the effective reach of Spectre V1 leaks — at virtually zero CPU cost — and forces attackers to contend with type segregation. This mitigation makes it impractical for attackers to use Spectre V1, as they would typically need 25 or more V1 sequences to reach more than 95 percent exploitability rate — unless one of these sequences is related to the bug being exploited, following similar reasoning as our kalloc_type analysis.

Did they ever explain what that mitigation does?

▲

saagarjha 3 days ago | parent | next [-]

https://mastodon.online/@ezhes_/115175838087995856

▲

sfink 3 days ago | parent | prev [-]

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)

▲

eigenform 2 days ago | parent | next [-]

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...

▲

MBCook 3 days ago | parent | prev [-]

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.

▲

saagarjha 3 days ago | parent | next [-]

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.

▲

achierius 3 days ago | parent | prev [-]

> 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.

	▲	3 days ago \| parent [-]
		[deleted]