hooks plugin is slow

[MarkMankins]

There are a couple of cases where plugins load the hooks plugin. The callbacks invoked by hooks significantly slow down panda. We should consider whether loading hooks by default is correct in all cases. Maybe just adding a warning along with a method to disable the use of hooks would be enough - which wouldn't break anything if anyone is relying on the current behavior.

One instance where I'm seeing this is when an osi_linux kernel profile includes the optional parameter task.switch_hook_addr. In my case I got a 4x speed boost by using an updated profile with this parameter commented out.

Another case I'm seeing this is when the wintrospection plugin is loaded. In my case, I didn't need the functionality that wintrospection was leveraging from hooks so I updated wintrospection to not load hooks. This change cut my analysis time by a third.

Wondering if others are affected by either of these issues and may not be aware.

[lacraig2]

I suspect this isn't a hooks issue. Primarily because hooks is used all over the place and in this case is probably running in both cases of your test.

In particular, if you load osi_linux by default we also load syscalls2:

panda/panda/plugins/osi_linux/osi_linux.cpp

Line 1306 in c363487

panda_require("syscalls2");

And syscalls2 can't run without hooks:

panda/panda/plugins/syscalls2/syscalls2.cpp

Lines 1398 to 1403 in c363487

	void *hooks = panda_get_plugin_by_name("hooks");
	if (hooks == NULL){
	panda_require("hooks");
	hooks = panda_get_plugin_by_name("hooks");
	}
	hooks_add_hook = (void(*)(struct hook*)) dlsym(hooks, "add_hook");

Because hooks is running in both scenarios I suspect the slowdown has to be related with what is running on the task switch callback than it could with hooks itself.

FWIW: I don't tend to use the task.switch_hook_addr functionality.

[MarkMankins]

Interesting - I assumed this was happening in hooks because I was profiling panda and seeing the majority of the time was being spent in panda_hooks.so - but I certainly could have misinterpreted what I was seeing - I can take a closer look and try to isolate where the slowdown might be occurring.