I'm going to be that jerkface and predict that MTE won't do all that much. It's a pretty weak mitigation that requires a lot of work to adopt.
-
-
Replying to @Gok @johnregehr
MTE requires relatively little work to adopt (I say this as someone who's adamant about not adopting invasive "hardening" snakeoil like CET) and completely closes off huge classes of vulns.
3 replies 0 retweets 4 likes -
Sequential buffer overflows (out of object) are completely impossible. Attack of heap metadata is impossible without ability to craft upper ptr bits. Clobbering new object via UAF is impossible to prevent 100% but statistically very likely to trap.
1 reply 0 retweets 0 likes -
…unless the attacker can get the tag of the freed area somehow, which is one instruction away. That’s the scary part.
1 reply 0 retweets 0 likes -
If they have code execution already, you're outside the scope of what MTE is protecting against. That's the scope of anti-ROP snakeoil like CET. The point of MTE is to prevent getting there in the first place.
1 reply 0 retweets 0 likes -
Scenario: Attacker has a UAF vuln and some ability to read the address of newly allocated pointers via a leak. Attacker causes object to be freed with a dangling pointer. Attacker repeatedly reallocates and frees objects in that area, checking pointers, until tag matches.
2 replies 0 retweets 1 like -
Replying to @pcwalton @RichFelker and
Then UAF becomes exploitable again. This shows the weakness of 4-bit tag: doesn’t take many allocations to get a collision.
2 replies 0 retweets 0 likes -
How about rv128 with 80 bit tags?
1 reply 0 retweets 2 likes -
Clearly the answer is to store pointers in the x87 floating point registers and put the tag in the top 16 bits
1 reply 0 retweets 3 likes -
How about the top 448 bits of %zmm*?
1 reply 0 retweets 0 likes
Even better
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.