By a pure casualty, I discovered that a process is taking 100% of one core sometimes when I am away of my computer: When using the CPU, it is below 1%, but when the computer is IDL, meaning the screen is off and nobody touch the PC for a while, this process some times start to make intensive use of the CPU. As soon as any input wake-up the screen, the process become "normal" again.

I created a script to log which process take lot of CPU and I found it is kwin (cmdline = kwin-session1011dcae5a5000144224709.....)

Something tell me that a window-manager should not use 100% CPU when the screen is off, so I am looking for any crack/hacking to my computer.

My question is:

  • What is the procedure to follow to know if this process is cracked/hacked?
  • Does this supposition make sense?

Note: I copied mostly the /proc/xxx folder so I have quite some information.

  • Would it be more likely that kwin has a bug? e.g. bugs.kde.org/show_bug.cgi?id=340294 "Bug 340294 - kwin_x11 sometimes goes up to 100% cpu usage and freezes the system" is just one such example
    – steve
    Nov 8, 2015 at 16:50

1 Answer 1

  • What is the procedure to follow to know if this process is cracked/hacked?

The only way to see what a single process does in a currently running system is to debug that process, or debug the whole system (kernel). The first is rather easy, and several tools allow you to do that live on the suspected process. You can strace what syscalls does it perform and ltrace to see what shared library functions does it call, or even gdb as a whole to see what instructions it currently executes. Not that for latter you will freeze that process (in default mode) as well as you need a source code of kwin laying in right place so gdb will able to load it and show you a line where it did stop. Otherwise it will show you only machine instruction with special commands.

To debug the kernel you need a special setup which is not probably possible for a situation of already running system (if it was not prepared for such a setup at boot time). It permits you to stop the whole system, locally (kgdb's kdb) or remotely (kgdb with gdb) and inspect memory, registers, and dump some useful information as well as disassembling the code. However to interpret it effectively you need to know at least the basics of x86 asm.

The kernel provides at least a pseudofile /proc/pid/mem which is unreadable in normal mode, but https://github.com/siblynx/lynxware/blob/master/dumpmem.c is a wrapper thing that reads this sparse file based on mappings provided in /proc/pid/maps. You can then inspect dumped file with disassembler. If you don't care about process state, you can force it to dump core with kill -SEGV pid, but if at launch time it was not permitted to dump core files (ulimit -c size), it will not dump core but will still die, losing any bits of info you want to get.

There are also more special forensics tools aimed at same task, but they usually target experienced people.

  • Does this supposition make sense?

I don't think so. I'd worried about a bit if my fvwm started to behave like that, or even twm (if I used to it), but as for kwin (and KDE in general) I expect that behavior from it because today's KDE is huge and such an activity is "normal" for it.

If it was such a behavior with fvwm for example, I'd first checked that process' /proc/pid/exe points to right binary, then checked creation time of that binary with stat -c %z /path/to/binary, then straced it if it was legitimate or rushed to my always ready kdb if not, freezing the system. Most of "wasted" activity is program bugs or software bloat.

  • Note: I copied mostly the /proc/xxx folder so I have quite some information.

This does not makes sense because /proc files are purely virtual, and some important of them (like the mem pseudofile) are unreadable when requested in casual way.

  • A great answer, I will try Nov 9, 2015 at 18:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .