Sophos Anti-Virus freeze/slowdown whole Linux when updating Wine package [Arch Linux]

It's nothing strange about it when the wine-2.13-1-x86_64.pkg.tar.xz contains 3223 dll/so files, so sophos is trying to check every file on update, it does the job as intended, but it should not affect my browser and any other apps while cpu/core/memory/hd is not peaking.

In log i read:

Wed Aug 16 11:07:48 2017: update.updated       Updated to versions - SAV: 10.2.0, Engine: 3.68.2, Data: 5.42
Wed Aug 16 11:07:48 2017: update.updated       Successfully updated Sophos Linux Security from sdds:SOPHOS
Wed Aug 16 12:07:46 2017: update.check         Successfully updated Sophos Linux Security from sdds:SOPHOS
Wed Aug 16 12:53:20 2017: savscand.control.log Additional scanning thread has been started  << probably started the wine package install/update
Wed Aug 16 12:53:22 2017: savscand.control.log Additional scanning thread has been started
Wed Aug 16 12:53:24 2017: savscand.control.log Additional scanning thread has been started
Wed Aug 16 12:53:26 2017: savscand.control.log Additional scanning thread has been started
Wed Aug 16 12:53:28 2017: savscand.control.log Additional scanning thread has been started
Wed Aug 16 12:57:48 2017: savd.daemon          On-access scanning disabled.
Wed Aug 16 12:57:56 2017: savd.daemon          Sophos Linux Security daemon stopped.  << i did stop the sophos av and the update finished instantly
Wed Aug 16 12:58:01 2017: savd.daemon          Sophos Linux Security daemon started.
Wed Aug 16 12:58:03 2017: talpa.startup        Unable to load Talpa modules.  << maybe related to why other app get slowed down
Wed Aug 16 12:58:08 2017: savd.daemon          On-access scanning enabled using fanotify.
Wed Aug 16 13:34:42 2017: savd.daemon          On-access scanning disabled.
Wed Aug 16 13:34:42 2017: savd.daemon          Sophos Linux Security daemon stopped.  << OS reboot
Wed Aug 16 13:35:01 2017: update.failed        Failed to replicate from sdds:SOPHOS
Wed Aug 16 13:35:01 2017: update.failed        Failed to replicate from all update sources
Wed Aug 16 13:35:03 2017: savd.daemon          Sophos Linux Security daemon started.
Wed Aug 16 13:35:05 2017: talpa.startup        Unable to load Talpa modules.
Wed Aug 16 13:35:14 2017: savd.daemon          On-access scanning enabled using fanotify.
Wed Aug 16 13:35:25 2017: savscand.control.log Additional scanning thread has been started
Wed Aug 16 13:35:31 2017: savscand.control.log Additional scanning thread has been stopped
Wed Aug 16 13:36:35 2017: savscand.control.log Additional scanning thread has been started
Wed Aug 16 13:36:37 2017: savscand.control.log Additional scanning thread has been started
Wed Aug 16 13:36:43 2017: savscand.control.log Additional scanning thread has been stopped
Wed Aug 16 13:36:53 2017: savscand.control.log Additional scanning thread has been stopped


Does the Talpa module fix the "antyvir busy - other app get slowed down" issue or it's not related?
Should Talpa compile from sources on start or i need to compile it manually?

Linux: Arch (unsupported)
Kernel: 4.12.6 ("bleading edge")

Keep up the good work and Thanks for great work with AV for Linux!

  • 4.12.6 is indeed too new for the Talpa that comes with 10.2.0 to compile.

    If you have a compile environment setup (gcc, make, kernel headers), then Talpa will try to compile. (The talpaselect.log in /opt/sophos-av/log will tell you why it is failing).

    If you want to get Talpa working then the github line has been updated to work with 4.12 kernels. This can be deployed using autodeploy.sh from https://gist.github.com/paperclip/7892031 .

     

    Unfortunately unpacking an archive full of dlls is probably the hardest thing to scan, each file will be scanned on-close (so asynchronously), keeping all the scan threads busy (hence why the extra scan threads are started). That should have kept either disk or CPU busy, and queued up other scan requests for e.g. your browser. Unfortunately the queuing of scan requests for fanotify is simple FIFO.

     

    The only thing that might have stalled it is LiveProtection? It might have been waiting for lookups for those dlls if something suspicious was found.

     

    Talpa has timeouts which might have recovered the system faster, without you needing to disable on-acccess.

  • In reply to DouglasLeeder:

    "That should have kept either disk or CPU busy, " the strange part was that cpu and disk was idle, so probably it was "it might have been waiting for lookups for those dlls if something suspicious was found" so network could affect the long time.

    As Arch is 'bleading edge' i probably will need to recompile it a lot, question what does it do? Is it a huge speed improvement/security concert or just really needed on heavy loads?
    I only finding that people have problem with loading talpa or other, but can't find what it is.

    Thanks once more.

  • In reply to Rafal Kolodziejczyk:

    fanotify and Talpa are the two ways of getting open/close operations from the kernel to the user-space scanner.

    fanotify is a kernel API available from 2.6.37 which provides notifications of file system operations to user-space, and allows user-space decisions to block opens.

    Talpa is a set of kernel modules provided by Sophos to do a similar job.

    Talpa provides some extensions over fanotify: timeouts in kernel, boot-sector scanning, support for older kernels, support for scanning across Containers.

    Talpa has to be compiled for each individual kernel, Sophos provides pre-compiled binary packs for some kernels for RHEL, Ubuntu etc. But for every other kernel local compilation is required.