Comment by toast0
4 days ago
Elsewhere in the thread, someone reports that with MTE enforcement enabled, there are lots of crashes. And app and system service developers don't seem responsive to them.
That's not something that's really acceptable on a $500+ phone... so if you're Google, you're not going to turn that on by default and you're not really going to be interested in keeping it as a feature that users can turn on.
Graphene has a different focus, so they can push the tradeoff towards enforcement and crashes rather than non enforcement and fewer crashes.
Google could perhaps do more with their crash logs and pushing app developers to fix MTE crashes, but they don't often do a lot of that; and they get called out for being developer unfriendly when they do enforcement.
That was partially true a couple years ago that there were some crashes related to it. It is absolutely not the case anymore.
Why not force it on an API change? It wouldn’t be the first time there was a breaking change.
Because it (anecdotally) crashes too much, but only on $$$ devices with cool CPUs that can use it. People buy expensive phones because they're supposed to work better.
They should really do some sort of sampling thing to generate crash dumps and find big offenders and increase the coverage over time.
For Google employee devices, 0.1% of background execution starts while charging in an idle period (overnight bedtime charging) will use MTE. When any specific device hits an MTE crash, back-off sampling for 1 week on that device. Modulate the sampling rate so crashes are manageable.
When Google employee devices are not crashing overnight at a high rate, then start sampling background execution during the day for employees and overnight background execution on general user devices. Finally, sample on foreground execution, again for Google employee devices first.
If there's significant variation in crashes by app, you probably need to setup a way to set sampling rates to zero or very low for application versions that have been identified as a known problem and don't need additional traces.
I wonder what causes the crashes. Is it a buggy MTE implementation (or buggy hardware), or are app devs doing something that would only cause crashes under MTE? Maybe it’s something they are using like a library or framework?
1 reply →