High CPU load in whonix-ws-14 AppVM & DispVM - related to notifications?

[githubhun1]

Qubes OS version
R4.0 and up

Affected component(s) or functionality
whonix-ws-14-dvm based AppVMs, DispVMs: Tor Browser, Tor connection notification widget

Brief summary
Tor Browser (process: firefox.real) is causing constant excessive CPU load (>150%), even if there's no web content displayed (empty page) in these two use cases:

1. Tor Browser window launches before sys-whonix displays notification "Connected to Tor". CPU load in AppVM jumps up and remains there until Tor Browser is closed and re-opened again
2. if system wakes up from sleep, then Tor Browser is launched, a few second later (presumably, when sys-whonix reconnects to Tor and would send the notification) CPU load jumps up and remains there until Tor Browser is closed and re-opened again

To Reproduce
Steps to reproduce the behavior:
use case 1:

1. Start Qubes with sys-whonix not started automatically (or equally start with sys-whonix not running actually).
2. Try to open any Tor Browser window in a whonix-ws AppVM or DispVM
3. Wait until Tor Browser window appear
4. Check AppVM or DispVM CPU usage in Dom0 with xentop or top/htop in AppVM, after "Connected to tor network" notification is displayed.

use case 2:

1. Make sure sys-whonix is running
2. Suspend/Resume system
3. Lauch Tor Browser window in a whonix-ws-14 based AppVM or DispVM
4. Wait until Tor Browser window appear
5. Check AppVM or DispVM CPU usage in Dom0 with xentop or top/htop in AppVM or DispVM

Expected behavior
No hang processes in AppVM or DispVM

Actual behavior
Constant CPU usage >150% in the respective AppVM or DispVM. Requesting new identity in TB doesn't solve the issue, only closing Tor Browser and reopening again seem to help.
You can still browse despite the high CPU usage, however system is very slow and CPU fans constantly operate at high speed.

Screenshots
N/A

Additional context
This might be connected to sys-whonix notification scripts, or the way sys-whonix checks if connection to Tor is verified. In use case 1, browsing is already working before the notification is being shown, there could be few seconds - max 10-15s - delay for the notification to appear. After the initial notification ("Connected to Tor") no further notifications appear, but use case2 still exist.
Might be also worth checking if there could be any security implications (anonymity) for having that hang "Firefox.real" process, before the connection to tor is presumably verified

Solutions you've tried
Workaround: close and re-open Tor Browser - not too convenient in DispVM

Relevant documentation you've consulted
N/A
Related, non-duplicate issues
Could be related to "Launching Tor Browser in anon-whonix AppVM results in torbrowser script bug #4311"

[farrilis]

I can confirm this issue, except:

• no pre-conditions required, firefox.real process causes CPU spike for all whonix 14 DVM instances when opening Tor Browser

Tor Browser is unusable until the process returns to low CPU usage (takes 30secs to 1 minute).

No such problems opening regular Firefox in Debian 9 DVM, or opening Whonix 14 DVM with e.g. Konsole

[iprid23]

Confirming random high load occasionally in WhonixVM's firefox.real right after starting the browser and without even interacting with it.

[adrelanos]

From https://www.whonix.org/wiki/Tor_Browser#Tor_Browser_Functionality_on_Different_Platforms

It is not valid to make a comparison between the Windows version of TBB and the Whonix ™ Tor Browser concerning functionality, for instance why the warning message does not appear in Whonix ™ when maximizing the browser window. [104]

The reason is this comparison includes a host of platform-specific differences which confound the result. For example, a more valid comparison would examine the differences between:

• TBB in Debian (real Debian, not in Qubes) versus Tor Browser in Non-Qubes-Whonix ™.
• TBB in a Qubes AppVM based on a Debian TemplateVM versus Tor Browser in Qubes-Whonix ™.

Similarly, these comparisons would be helpful in order to help with TBB (non-Whonix ™) development:

• TBB in Debian (real Debian, not in Qubes) vs TBB in Windows.
• TBB in different Linux distributions.
• TBB in different Windows platforms.

[adrelanos]

In other words, could you please compare TBB in a Qubes Debian VM with TBB in a Whonix 14 VM?

• Whonix 14 jessie based, compare with: Qubes jessie Debian 9 template
• Whonix 15 buster based, compare with: Qubes buster Debian 10 template

[tasket]

I have the same problem with whonix-ws-15: firefox.real pegging CPU at about 150% on dual processor systems, which become hot and noisy. Of course, this greatly impacts other processes.

Once I notice the high load it doesn't stop if I simply close all tabs (except a blank). Repeatability is eluding me atm.

I do have Apparmor enabled, and wonder if that's a factor.

[trocoinone]

Same here, anon-whonix (whonix-ws-15), after some time torbrowser starts to eat CPU. Closing tabs does not help.
top shows firefox.real eating ~120% cpu and top -H shows two threads:
firefox.real (~80%)
and some Socket thread (~30%cpu)

Then I tried to pause VM, and upon Unpause all Vm windows disappeared (torbrowser, terminal) and VM became unreachable. Only shutdown helped.

[trocoinone]

It happens every time I use it, after 10-20-30-60 minutes, url does not matter - once it happened on qubes documentation website.

[exquo]

This appears to be related to the sdwdate process. Stopping sdwdate in sys-whonix and restarting Tor Browser prevents the problem from re-occuring. This can be done through the sdwdate icon in the system tray.

The problem seems to be caused by the interaction between sdwdate in sys-whonix and the Tor Browser in anon-whonix. The firefox.real process starts to eat CPU after sdwdate in sys-whonix successfully updates. This can be observed by

1. launching Tor Browser in anon-whonix
2. suspending and then waking up the computer OR stopping and then restarting sdwdate in sys-whonix
   When sdwdate in sys-whonix reports success (can watch it by right-clicking on the tray icon and waiting the clock / globe icon next to sys-whonix to turn green), the Tor Browser process in anon-whonix starts to consume CPU. Note that the sdwdate in anon-whonix does not cause high CPU use.

Incidentally, after sdwdate is stopped in sys-whonix, sys-whonix VM's clock does not to go out of sync (checked by running date in it periodically), so looks like there there are no repercussions caused by doing this.

@adrelanos, confirming that this does not happen with the Tor Browser Bundle on Debian 10 based VM. This is to be expected if this is indeed the problem with sdwdate, as it's a component of Whonix and not the standalone Tor Browser.

[adrelanos]

Confirmed. Happens with Non-Qubes-Whonix-only.

Still not "really" a Whonix issue. Also not "really" an sdwdate issue. I suspect it is this:

• Tor Browser is running on one machine and talking to Tor on another machine.
• When time is changed using date on another machine, Tor Browser starts to use 100% CPU.

It still needs to be reproduced without mentioning Whonix / sdwdate as a general bug and then reported against Tor Project trac component Tor Browser.

Help welcome.

[andrewdavidwong]

Confirmed. Happens with Non-Qubes-Whonix-only.

It sounds like this should not be in qubes-issues, then. Closing as "not our bug." If you believe this is a mistake, please leave a comment, and we'll be happy to take another look. Thank you.