Detect which process(es) is(are) blocking procmon's unload

[alexandernst]

When a hijacked syscall is called, it should store the PID of the process which called it, and when it's done, it should remove that PID.
This way we'll be able to tell which process(es) is(are) blocking procmon's unloading process.

EDIT: Depends on #31

[alexandernst]

@milabs I firstly thought this was based on processes blocking the release, but it seems that's not 100% true. For example, if I turn on procmon (state=1) and then I open ksysguard (KDE's task manager) and then I close it, I still can't unload procmon until I open ksysguard once again.

Why could that be?

[milabs]

@alexandernst

Well, it's the result of the hooking technique. Let's look at how it's happend:

sys_call_table[__NR_read]
    -> hooked_sys_read
        -> sys_read_pre_hook_action
        -> ret = real_sys_read (can take a long time...)
        -> sys_read_post_hook_action

So, the problem is that when we unloading the module while real_sys_read is in kernel we get fault when it returns as there no module code in kernel. Now, we implement some logic so we'are looking for counters which tells us if there is a hook that is in kernel while unloading. OK, got it.

But the next problem is that we don't know exactly how to do with such processes that sleeps near infinite time in the kernel. We can wait a lot and unload the module, but it leads to accidental crashes. Not the best case :)

As I see it the possible solution is to create stubs like that:

sys_read_stub:
    call sys_read_pre_hook_action
    call real_sys_read
    call sys_read_post_hook_action
    RET

Now, when we need to unload the module, we modify such stubs to looks like that:

sys_read_stub:
    nop nop nop nop nop
    call real_sys_read
    nop nop nop nop nop
    RET

Now, we unloading but don't touch these stubs. I meant that we don't free allocated area (which has exec permissions).

The one problem here is that we eat some kernel's memory per load/unload cycle. But I can't see any other method to allow safely unloading the module.

What do you think?

[alexandernst]

@milabs But that will happen if we alloc N bytes of memory for that stub and then unload the module (not state=0 but rmmod procmon)? Won't that stub memory just disappear (thus causing a crash in the sleeping processes)?

[milabs]

@alexandernst As the stub resides in memory after unloading nothing bad happens when the real_sys_read returns, for ex.

[alexandernst]

@milabs Can you do a simple POC, please?

[milabs]

@alexandernst Not now... Create and assign an issue please?

[alexandernst]

@milabs Sure ;)

[alexandernst]

Closing this as I just implemented #31. This is not needed anymore.