Skip to content
Snippets Groups Projects
New look: Off

Enable Fuzzyfox

    • Closed (moved) Issue created by Tom Ritter @tjr

    Fuzzyfox is a new timer mitigation technique currently in Nightly. https://bugzilla.mozilla.org/show_bug.cgi?id=fuzzyfox

    There are some open issues on it that would be best to solve before enabling it by default, but this bug can serve as a tracker for either backporting it or evaluating it.

    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items ...

    • Activity

    • Tom Ritter added GeorgKoppen201910 TorBrowserTeam201910 actualpoints::0.5 component::applications/tor browser owner::tbb-team parent::28707 points::0.1 priority::medium severity::normal status::reopened type::defect labels

      added GeorgKoppen201910 TorBrowserTeam201910 actualpoints::0.5 component::applications/tor browser owner::tbb-team parent::28707 points::0.1 priority::medium severity::normal status::reopened type::defect labels

    • S
      Matthew Finkel @sysrqb ·

      We should try enabling this after the 68esr transition.

      Trac:
      Summary: Backport Fuzzyfox to Enable Fuzzyfox
      Keywords: N/A deleted, TorBrowserTeam201911 added

    • Georg Koppen
      Georg Koppen @gk ·

      That seems to be a pref flip away (privacy.fuzzyfox.enabled). We should pick that for 9.5a1.

    • Georg Koppen
      Georg Koppen @gk ·

      Replying to gk:

      That seems to be a pref flip away (privacy.fuzzyfox.enabled). We should pick that for 9.5a1.

      bug_28709 (https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_28709&id=198d9ec1b5cb68649963e425ac7734bf69dff263) in my tor-browser repository has that change.

      Trac:
      Actualpoints: N/A to 0.1
      Status: new to needs_review
      Points: N/A to 0.1
      Keywords: TorBrowserTeam201911 deleted, GeorgKoppen201910, TorBrowserTeam201910R added

    • S
      Matthew Finkel @sysrqb ·

      It looks simple and good.

      Trac:
      Status: needs_review to merge_ready

    • Georg Koppen
      Georg Koppen @gk ·

      Thanks. Cherry-picked onto tor-browser-68.2.0esr-9.5-1 (commit 81d2d351b4c93e139f13a6f21a9abadedc86ee6c). Let's see how it goes. :) (Thanks tjr for all the work here)

      Trac:
      Resolution: N/A to fixed
      Status: merge_ready to closed

    • S
      Matthew Finkel @sysrqb ·

      It looks like this is causing startup problems. When it is enabled, the browser doesn't start on macOS or linux (64bit). macOS was reported by rex. I don't have logs yet.

      Trac:
      Status: closed to reopened
      Resolution: fixed to N/A

    • S
      Matthew Finkel @sysrqb ·

      Disabling fuzzyfox in the profile's prefs.js results in the browser starting.

    • Trac
      Trac @tracbot ·

      Trac:
      Username: rex4539

      tor_browser_macos.log

    • Trac
      Trac @tracbot ·

      Trac:
      Username: rex4539

    • Trac
      Trac @tracbot ·

      Attached system log from macOS.

      Trac:
      Username: rex4539

    • S
      Matthew Finkel @sysrqb ·

      I think the reason shutting down hangs is because Fuzzyfox doesn't stop dispatching an event for itself, so it continues (effectively) looping.

      I don't know why the browser window isn't rendered, yet.

      0x00007f1443d6b670 in __GI___nanosleep (requested_time=requested_time@entry=0x7ffcc25d0320, remaining=remaining@entry=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
28	../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
(gdb) bt
#0  0x00007f1443d6b670 in __GI___nanosleep (requested_time=requested_time@entry=0x7ffcc25d0320, remaining=remaining@entry=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
#1  0x00007f1443d9e894 in usleep (useconds=<optimized out>) at ../sysdeps/posix/usleep.c:32
#2  0x00007f143da7b572 in mozilla::Fuzzyfox::Run (this=0x7f1437c09780) at /var/tmp/build/firefox-81d2d351b4c9/toolkit/components/fuzzyfox/Fuzzyfox.cpp:215
#3  0x00007f143adbfdc6 in nsThread::ProcessNextEvent (this=0x7f1438814040, aMayWait=<optimized out>, aResult=0x7ffcc25d0447) at /var/tmp/build/firefox-81d2d351b4c9/xpcom/threads/nsThread.cpp:1175
#4  0x00007f143adbe68e in NS_ProcessPendingEvents (aThread=0x7f1438814040, aTimeout=4294967295) at /var/tmp/build/firefox-81d2d351b4c9/xpcom/threads/nsThreadUtils.cpp:434
#5  0x00007f143add8050 in mozilla::ShutdownXPCOM (aServMgr=0x7f143882f168) at /var/tmp/build/firefox-81d2d351b4c9/xpcom/build/XPCOMInit.cpp:625
#6  0x00007f143dbddb52 in ScopedXPCOMStartup::~ScopedXPCOMStartup (this=0x7f1443ae7580) at /var/tmp/build/firefox-81d2d351b4c9/toolkit/xre/nsAppRunner.cpp:1249
#7  0x00007f143dbe4305 in mozilla::DefaultDelete<ScopedXPCOMStartup>::operator() (aPtr=0x7f1443ae7580, this=<optimized out>)
    at /var/tmp/build/firefox-81d2d351b4c9/obj-x86_64-pc-linux-gnu/dist/include/mozilla/UniquePtr.h:486
#8  mozilla::UniquePtr<ScopedXPCOMStartup, mozilla::DefaultDelete<ScopedXPCOMStartup> >::reset (this=<optimized out>, aPtr=0x0)
    at /var/tmp/build/firefox-81d2d351b4c9/obj-x86_64-pc-linux-gnu/dist/include/mozilla/UniquePtr.h:323
#9  mozilla::UniquePtr<ScopedXPCOMStartup, mozilla::DefaultDelete<ScopedXPCOMStartup> >::operator=(decltype(nullptr)) (this=<optimized out>)
    at /var/tmp/build/firefox-81d2d351b4c9/obj-x86_64-pc-linux-gnu/dist/include/mozilla/UniquePtr.h:296
#10 XREMain::XRE_main (this=0x7ffcc25d05b0, argc=<optimized out>, argv=<optimized out>, aConfig=...) at /var/tmp/build/firefox-81d2d351b4c9/toolkit/xre/nsAppRunner.cpp:4972
#11 0x00007f143dbe4775 in XRE_main (argc=0, argv=0x0, aConfig=...) at /var/tmp/build/firefox-81d2d351b4c9/toolkit/xre/nsAppRunner.cpp:5026
#12 0x000055cdb79fc050 in do_main (argc=0, argv=<optimized out>, envp=<optimized out>) at /var/tmp/build/firefox-81d2d351b4c9/browser/app/nsBrowserApp.cpp:217
#13 main (argc=<optimized out>, argv=<optimized out>, envp=0x7ffcc25d1868) at /var/tmp/build/firefox-81d2d351b4c9/browser/app/nsBrowserApp.cpp:296
    • S
      Matthew Finkel @sysrqb ·

      Hrm. I'm not sure if Fuzzyfox is starving the event loop, or Fuzzyfox is somehow preventing other events triggering.

      This is the stacktrace from attaching gdb on the child process. It doesn't tell us much.

      Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f259a59a670 in __GI___nanosleep (requested_time=requested_time@entry=0x7ffe6ca70540, remaining=remaining@entry=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
28	../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
(gdb) bt
#0  0x00007f259a59a670 in __GI___nanosleep (requested_time=requested_time@entry=0x7ffe6ca70540, remaining=remaining@entry=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
#1  0x00007f259a5cd894 in usleep (useconds=<optimized out>) at ../sysdeps/posix/usleep.c:32
#2  0x00007f25942c8572 in mozilla::Fuzzyfox::Run (this=0x7f258cecca40) at /var/tmp/build/firefox-81d2d351b4c9/toolkit/components/fuzzyfox/Fuzzyfox.cpp:215
#3  0x00007f25915ff82a in mozilla::SchedulerGroup::Runnable::Run (this=0x7f258b1304c0) at /var/tmp/build/firefox-81d2d351b4c9/xpcom/threads/SchedulerGroup.cpp:295
#4  0x00007f259160cdc6 in nsThread::ProcessNextEvent (this=0x7f258d071b80, aMayWait=<optimized out>, aResult=0x7ffe6ca706d7) at /var/tmp/build/firefox-81d2d351b4c9/xpcom/threads/nsThread.cpp:1175
#5  0x00007f259160ea16 in NS_ProcessNextEvent (aThread=0x7ffe6ca70540, aMayWait=<optimized out>) at /var/tmp/build/firefox-81d2d351b4c9/xpcom/threads/nsThreadUtils.cpp:486
#6  0x00007f2591a2baf7 in mozilla::ipc::MessagePump::Run (this=0x7f259a29f560, aDelegate=0x7ffe6ca70800) at /var/tmp/build/firefox-81d2d351b4c9/ipc/glue/MessagePump.cpp:88
#7  0x00007f25919f8088 in MessageLoop::RunInternal (this=<optimized out>) at /var/tmp/build/firefox-81d2d351b4c9/ipc/chromium/src/base/message_loop.cc:315
#8  MessageLoop::RunHandler (this=<optimized out>) at /var/tmp/build/firefox-81d2d351b4c9/ipc/chromium/src/base/message_loop.cc:308
#9  MessageLoop::Run (this=0x0) at /var/tmp/build/firefox-81d2d351b4c9/ipc/chromium/src/base/message_loop.cc:290
#10 0x00007f25935bc766 in nsBaseAppShell::Run (this=0x7f258ceef520) at /var/tmp/build/firefox-81d2d351b4c9/widget/nsBaseAppShell.cpp:137
#11 0x00007f2594432d60 in XRE_RunAppShell () at /var/tmp/build/firefox-81d2d351b4c9/toolkit/xre/nsEmbedFunctions.cpp:926
#12 0x00007f25919f8088 in MessageLoop::RunInternal (this=<optimized out>) at /var/tmp/build/firefox-81d2d351b4c9/ipc/chromium/src/base/message_loop.cc:315
#13 MessageLoop::RunHandler (this=<optimized out>) at /var/tmp/build/firefox-81d2d351b4c9/ipc/chromium/src/base/message_loop.cc:308
#14 MessageLoop::Run (this=0x0) at /var/tmp/build/firefox-81d2d351b4c9/ipc/chromium/src/base/message_loop.cc:290
#15 0x00007f2594432bea in XRE_InitChildProcess (aArgc=<optimized out>, aArgv=<optimized out>, aChildData=<optimized out>) at /var/tmp/build/firefox-81d2d351b4c9/toolkit/xre/nsEmbedFunctions.cpp:764
#16 0x000055a79de5deb9 in content_process_main (bootstrap=0x7f259a22a690, argc=18, argv=<optimized out>) at /var/tmp/build/firefox-81d2d351b4c9/browser/app/../../ipc/contentproc/plugin-container.cpp:56
#17 main (argc=<optimized out>, argv=0x7ffe6ca71ba8, envp=0x7ffe6ca71c48) at /var/tmp/build/firefox-81d2d351b4c9/browser/app/nsBrowserApp.cpp:268
    • Georg Koppen
      Georg Koppen @gk ·

      It seems even the earliest nightly with FuzzyFox support is affected by the shutdown issue. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1589958 for it.

    • Georg Koppen
      Georg Koppen @gk ·

      Okay, I was still not able to track down the reason for the startup hangs. I don't hit any assertions in a debug build and trying to figure out preferences we set and which could interfere was futile as well.

      For a while it seemed as if Tor Launcher related preferences could have played a role but that was visible in bundles that were not freshly extracted. Restricting myself to only clean, new bundles showed that even removing all of our default preferences we set (besides privacy.fuzzyfox.enabled) did not solve the problem. And removing all Tor Launcher bits from omni.ja did not change things either.

      I guess the next thing we could do is bisecting our patches to figure out which Firefox change is actually causing this problem. However, depending on where the problem actually lies, this is currently not trivial. #31918 (moved) should help with that.

      Trac:
      Actualpoints: 0.1 to 0.5

    • Thorin
      Thorin @thorin ·

      FWIW: I tried this a few days ago in FF68 on Windows and got hung processes on shutdown, so it's not necessarily a Linux thing here

    • Georg Koppen
      Georg Koppen @gk ·

      Trac:
      Cc: N/A to tom

    • Georg Koppen
      Georg Koppen @gk ·

      Trac:
      Keywords: TorBrowserTeam201910R deleted, TorBrowserTeam201910 added

    • Trac changed time estimate to 48m

      changed time estimate to 48m

    • Trac added 4h of time spent

      added 4h of time spent

    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    Please register or sign in to reply