Don't panic now, but LLM-based agent discovered a previously unknown real-world vulnerability. Details in https://googleprojectzero.blogspot.com/2024/10/from-naptime-to-big-sleep.html

The bug in question: https://project-zero.issues.chromium.org/issues/372435124

Recently, I tried running TinyInst against a target written in Objective C and... the performance was ... not great. Let's analyze why that was and how to fix it:

Firstly, technical background: TinyInst marks the code sections of instrumented modules non-executable. Then (being a debugger), it catches exceptions raised while attempting to execute the original code and redirects execution to the rewritten code instead.

Exception handling is not very fast, but it only happens when non-instrumented code calls into an instrumented module. All callls from instrumented into instrumented code get optimized. This is why TinyInst works best when instrumented modules are selected so that they form a whole and calls into their group happen rarely. A handful is fine, but you'll notice if there are thousands.

How does Objective C mess this up? Because method calls in Objective C happen through objc_msgsend, which is a part of libobjc module. So even if you have calls from module abc to the same module, What you end up with is abc->libobjc->abc.

If libobjc is not instrumented, then libobjc->abc transitions will cause slowdowns. On the other hand, if you do instrument libobjc, then any Objective C calls from any non-instrumented module will cause slowdowns. So, no good solution, right?

But what if we instrument libobjc ins such a way that it only runs instrumented if it's called from other instrumented code? This is surprisingly simple to implement, we just skip marking its code non-executable during instrumentation, but it will still runs instrumented code when called from other instrumented code due to optimization mentioned earlier.

The effect: an order of magnitude better performance and we get libobjc instrumented "for free" (it doesn't cause any additional entries)

This is now implemented in TinyInst in the form of -instrument_transitive, which will instrument a module only for calls from other instrumented modules.

tl;dr if you run Objective C code under TinyInst and are experiencing slowdownsm, try -instrument_transitive libobjc.A.dylib. But it will no doubt improve performance in other scenarios as well.