6 ms·
You wouldn't release with that on, and for testing you would have needed to craft a relevant input to detect it or fuzzed it.
by Zitrax 7y ago
You wouldn't release with that on, and for testing you would have needed to craft a relevant input to detect it or fuzzed it.
- kccqzy 7y agoWhy wouldn't you release with sanitizers on? The performance impact really is negligible depending on the workload. It's basically like that tiny slowdown when you go from C++ to Java. If you have benchmarks showing the slowdown is acceptable, just ship with it enabled. Saves lots of headaches.
- archi42 7y agoThis is actually a good point. I suspect using asan on this lib as it used by WA would have had a negligble performance impact on the overall UX. (That is, assuming asan would have really captured this specific instance).
- gpderetta 7y agoIs it though? I suspect that the cost of the sanitizer is significantly higher than the overhead of switching, say, to Java. Not that I don't appreciate sanitizers, I just used asan to find the cause of a memory corruption bug just a couple of hours ago and it was great. In the past I would have used valgrind which is significantly slower.
- pnako 7y agoMight be true for UBSan and LSan, that have a moderate impact, but not for ASan and certainly not for MSan or TSan. (as a _very_ crude approximation, with UBSan on, you have the performance of Java or Go, and with the other sanitizers you get closer to Ruby territory) You can't combine the sanitizers anyway. They're really designed to be enabled for a testsuite and debug builds.
- pjmlp 7y agoSure you would. This kind of attacks keep forcing Google security team to increasingly lock down Android native code, including shipping some sanitizers enabled in production devices. https://security.googleblog.com/2019/05/queue-hardening-enhancements.html?m=1 https://security.googleblog.com/2019/05/queue-hardening-enha...