Date: Mon, 25 Aug 2014 11:42:04 -0500 From: Nathan Dautenhahn <dautenh1@illinois.edu> To: Dieter BSD <dieterbsd@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: stopped processes using cpu? Message-ID: <20140825164204.GB47394@trypticon.cs.illinois.edu> In-Reply-To: <CAA3ZYrBRTkZppn26nv2w17mgXN-38N6t5hqy4bhKX2AR8s6xEA@mail.gmail.com> References: <CAA3ZYrBRTkZppn26nv2w17mgXN-38N6t5hqy4bhKX2AR8s6xEA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 20, 2014 at 01:52:41PM -0700, Dieter BSD wrote:
> > whether or not the existing code is good or bad
>
> It has been awhile since I've looked at the code for firefox, but
> that code was OBSCENELY bad. :-( I fixed hundreds and hundreds and
> hundreds of bugs (yes, that many!) and it still didn't work (at all).
> The firefox idiots didn't believe my bug report.
>
> Code quality of top/ps/kernel? Look at the code and/or see how many
> open PRs there are.
>
> Firefox runs in a chroot, executables in a read-only partition.
> /etc/profile has
> ulimit -S -m 400000
> ulimit -S -v 600000
> after an incident where an "idle" firefox grew without bound kicking
> everything else out of memory including a small program running at rtprio
> logging true real-time data resulting in the loss of data. (the data buffer
> was mlocked, but the code wasn't. Silly me thinking that the kernel
> wouldn't page out a small loop that is constantly running.)
> Firefox is usually stopped when not being actively used. No plugins.
>
> Other web browsers (smaller, faster, more secure, less buggy, ...)
> are used whenever possible.
>
> Rootkit? Perhaps possible in theory, but very highly unlikely.
I concur. I have been doing a lot of rootkit research lately, which bends the
mind that direction: if I wanted to hide a process that is doing nefarious
things it seems like Firefox, given the evidence you just mentioned, would be
ideal.
I won't lie though, I am not expertized enough to know how to really bite into
this and figure it out.
>
> CPU% decays as expected when processes are stopped (except for firefox).
> Firefox CPU% does not decay as expected, either running or stopped. I tried
> running a cpu-bound process in the same chroot as firefox, it decayed as
> expected when stopped.
>
> So firefox seems to be the only thing that this shows up on. And also seems
> to be the only thing with THR > 1. So try the -H option:
>
> PID UID PRI NICE SIZE RES STATE TIME WCPU COMMAND 92986
> 941 54 0 167M 63524K STOP 0:00 5.03% {firefox-bin} 92986
> 941 4 0 167M 63524K STOP 0:25 0.00% {initial thread} 92986
> 941 44 0 167M 63524K STOP 0:01 0.00% {firefox-bin} 92986
> 941 44 0 167M 63524K STOP 0:00 0.00% {firefox-bin} 92986
> 941 44 0 167M 63524K STOP 0:00 0.00% {firefox-bin} 92986
> 941 44 0 167M 63524K STOP 0:00 0.00% {firefox-bin} 92986
> 941 44 0 167M 63524K STOP 0:00 0.00% {firefox-bin} 33796
> 941 44 0 5248K 1200K ttyin 0:00 0.00% bash 92986 941 44
> 0 167M 63524K STOP 0:00 0.00% {firefox-bin} 92986 941 44 0
> 167M 63524K STOP 0:00 0.00% {firefox-bin} 92979 941 48 0
> 6184K 632K STOP 0:00 0.00% sh 92983 941 62 0 6208K 660K
> STOP 0:00 0.00% sh 92978 941 44 0 8296K 1372K STOP 0:00
> 0.00% sh
>
> PID UID PRI NICE SIZE RES STATE TIME WCPU COMMAND 44188
> 937 4 0 303M 187M STOP 104:11 12.65% {initial thread} 44188
> 937 44 0 303M 187M STOP 0:45 0.49% {firefox-bin} 44188
> 937 44 0 303M 187M STOP 8:19 0.29% {firefox-bin} 44188
> 937 44 0 303M 187M STOP 0:02 0.00% {firefox-bin} 44188
> 937 44 0 303M 187M STOP 0:01 0.00% {firefox-bin} 44188
> 937 44 0 303M 187M STOP 0:01 0.00% {firefox-bin} 44188
> 937 44 0 303M 187M STOP 0:00 0.00% {firefox-bin} 44188
> 937 44 0 303M 187M STOP 0:00 0.00% {firefox-bin} 44167
> 937 44 0 5248K 804K ttyin 0:00 0.00% bash 44181 937 76
> 0 6184K 632K STOP 0:00 0.00% sh 44185 937 76 0 6208K
> 664K STOP 0:00 0.00% sh 44188 937 60 0 303M 187M STOP
> 0:00 0.00% {firefox-bin}
>
> Any clues there?
Not that I can see. From what I know, if you are entertaining the possibility
it's a rootkit, the only direction would be to write a different utility that
printed out data on the various process lists in the kernel. You could use this
to see if any of the state isn't matching.
Sorry for not having more detailed ideas/evidence to go upon.
Best,
::nathan::
>_______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe,
> send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140825164204.GB47394>