Earlier quoted context omitted.
There's only a significant cost to synchronous MTE. MTE ships two modes. synchronous mode and asynchronous mode. SYNC is slower but gives you far better traces and throws an SEGV_MTESERR as soon as violations happen. ASYNC however is async so there's a bit of a delay between a violation and the "catch" that throws SEGV_MTEAERR. Strictly speaking async is worse for security because there's a brief window of time where…
Given the current use of AI tools I would think that SEGV_MTESERR crashes would be low hanging fruit to fix. AI tools do ok with identifying memory corruption issues, given a smoking gun, in my experience.
Likewise if it's because a language is being lazy with how it handles memory (see: wireguard-go SEGV_MTESERR because golang's string implementation was being overly permissive with pointers).
And of course this only applies to SEGV_MTESERR. SEGV_MTESERR has a much higher runtime overhead that Google and co would not tolerate (but Graphene does) so they'd likely only be willing to use SEGV_MTEAERR which provides traces that point at a completely different place than where the fault occurred (but still provide a little bit of useful info).