Participate

Copyright © 2018 The Linux Foundation® . All rights reserved. Hyperledger is a trademark of The Linux Foundation. Hyperledger has registered trademarks and uses trademarks. For a list of trademarks of Hyperledger, please see our Trademark Usage page. Linux is a registered trademark of Linus Torvalds. Privacy Policy and Terms of Use.

Related:

Hardware Acceleration for Linux endpoints with AMD GPUs

Starting from version 2.5, HDX RTME supports hardware acceleration for video compression on Linux thin clients or fat clients with AMD GPU. Specifically, for video encoding RTME uses VCE 2.0 or higher. Video decoding has limited support because of some technical limitations, and it is disabled in RTME by default.

OMX IL is used for offload video processing to GPU.

Hardware video encoding on Linux could be disabled by registry key DisableOnboardHardwareH264Encoding (DWORD value 1-disabled or 0-enabled by default) in HKEY_CURRENT_USERSoftwareCitrixHDXRTConnectorMediaEngine

Ubuntu 16.04 environment set-up

Install AMD driver stack from https://www.amd.com/en/support/kb/faq/amdgpu-installation

Install kernel (example command line, latest available version should be used):

sudo dpkg -i linux-image-4.4.11-289-amd+_4.4.11-289-amd+-10.00.Custom_amd64.deb linux-headers-4.4.11-289-amd+_4.4.11-289-amd+-10.00.Custom_amd64.deb

sudo reboot

Install userspace:

Create local repository as it is described in amdgpu_UserGuide.pdf or proceed manually with dpkg.

NOTE:

To verify available package versions:

apt-cache policy <package name>

To overwrite ‘man’ or header files:

-o Dpkg::Options::=”–force-overwrite” (apt-get)

–force-overwrite (dpkg)

In case of unmet dependencies, you can resolve them by installing strictly with dpkg -i, pulling needed packages alongside.

During these steps, please, prefer packages from AMD driver stack. For isntance you may install “llvm-5.0-dev=5.0-519”, while “llvm-5.0-dev” will set up the latest Ubuntu package.

libllvm5.0 llvm-5.0-dev llvm-5.0-runtime llvm-5.0

llvm-runtime llvm-dev llvm

libdrm-dev libdrm-amdgpu1 libdrm-radeon1 libdrm2

libdrm-dev libdrm-amdgpu1 libdrm-radeon1 libdrm2

libva-dev libva1 libva-drm1 libva-egl1 libva-glx1 libva-tpi1 libva-wayland1 libva-x11-1 vainfo apt-cache policy libva-dev libva1 libva-drm1 libva-egl1 libva-glx1 libva-tpi1 libva-wayland1 libva-x11-1 vainfo

libegl1-mesa-dev libegl1-mesa-drivers libegl1-mesa libgbm-dev libgbm1 libgl1-mesa-dev libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libgles1-mesa-dev libgles1-mesa libgles2-mesa-dev libgles2-mesa libosmesa6-dev libosmesa6 libwayland-egl1-mesa libxatracker-dev libxatracker2 mesa-common-dev mesa-omx-drivers mesa-vdpau-drivers

gst-omx xserver-xorg-video-amdgpu

Install bellagio:

libomxil-bellagio0 (Generic core OMXIL implementation)

libomxil-bellagio-bin (to register available OMX components)

Register these components run omxregister-bellagio (from libomxil-bellagio-bin) with the noted above path.

  • Run omxregister-bellagio -l and you should get the following output:
  • *********************************
  • * List of registered components *
  • *********************************
  • Component OMX.mesa.video_decoder
  • supported formats:
  • OMX.mesa.video_decoder.mpeg2
  • OMX.mesa.video_decoder.avc
  • Component OMX.mesa.video_encoder
  • supported formats:
  • OMX.mesa.video_encoder.avc
  • Installed components and a path to the library are stored in an OMX registry file:
  • $ cat ~/.omxregister
  • /usr/lib/libomxil-bellagio0/libomx_mesa.so
  • ==> OMX.mesa.video_decoder ==> OMX.mesa.video_decoder.mpeg2:OMX.mesa.video_decoder.avc:
  • ==> OMX.mesa.video_encoder ==> OMX.mesa.video_encoder.avc:

Driver requirements:

These are described in AMD’s site https://www.amd.com/en/support/kb/faq/amdgpu-installation

RTME uses OMX API for video encoding and decoding.

This API is implemented by Bellagio OpenMAX IL (libomxil-bellagio0 and libomxil-bellagio-bin).


Hardware requirements: AMD GPU with VCE 2.0 or above. Specifically, Citrix is using Mullins and Carrizo.

Known limitations:

video encoding is supported on Mullins series only. Carrizo series were tested too, but problems were found with unstable video bitrate. As a result, a stream was encoded with poor quality.

video decoding is disabled by default, and could be enabled from registry on VDA. It was done because HW decoder introduces high latency up to 500ms.

It was found that described limitations became visible only on Linux platforms. The same GPU works great on Windows endpoints.

Related:

Improving Linux scan times??

I need a solution

Hello community,

We have been working with SEP 14.2.x on Linux machines for a little while now, and one of the consistent complaints is that scan times are taking too long…sometimes 72 hours. As it turns out, many of the machines with excessive scan times have NFS Shares. I have seen this article: https://support.symantec.com/us/en/article.TECH240… and realize that exclusions can be made, but unfortunately, there is no easy way for me to ask our thousands of Linux users, what directories are actually NFS Mounts.

My question, is anyone using SEP 14.2.x on their Linux machines in a corporate environment? If so, what policies have you implemented to improve the scan times, and or performance, of those Linux machines…or do you only rely on Autoprotect and skip scheduled scans altogether? If not, is there a more robust, centrally managed, AV solution for Linux machines?

We would like to stick with SEP as our Antivirus solution on Linux machines, but at this point, it feels like the SEP Linux Client will remain the overlooked Redheaded Step Child (no offense to any real readheaded step children), of SEP 14’s supported operating systems, at least for the foreseeable future.

Any thoughts or suggestions will be greatly appreciated.

-Mike

0

Related:

Sophos Anti-Virus for Linux and UNIX: Changes to supported platforms


Announced 30 June 2017 – As part of Sophos’ ongoing product lifecycle review process, we plan to update the platforms that are supported by the Sophos Anti-Virus for Linux and UNIX offerings. The changes are designed to enable Sophos to provide the strongest protection for the most popular platforms, and will affect the following:

The following sections are covered:

Applies to the following Sophos products and versions

Central Managed Threat Response [MTR] for Linux


The number of customers requiring Anti-Virus capabilities for legacy UNIX platforms continues to decline. Sophos plans to support the most popular platforms going forward, and plans to retire support for HP-UX.


The latest versions of many popular Linux distributions are now only available for 64-bit platforms. After June 30, 2018, with the exception of Red Hat Enterprise Linux 6, Sophos Anti-Virus for Linux will support 64-bit versions of Linux distributions only.

Update July 1, 2018: In line with previous communications, Sophos Anti-Virus for Linux now supports 64-bit platforms only, with the exception of Red Hat Enterprise 6.


The Sophos Anti-Virus for Linux agent currently includes a large number of pre-compiled Talpa Binary Packs for on-access scanning, many of which are for very old and deprecated kernel versions. Most customers use newer kernels in order to benefit from kernel enhancements and improved security, therefore Sophos plans to reduce the number of pre-compiled Talpa Binary Packs that are provided with the product.

  • When a new kernel version is introduced for a specific Linux distribution, Sophos typically aims to provide a Talpa Binary Pack for the new kernel version within approximately two to four weeks.
  • After June 2018, Talpa Binary Packs for kernel versions that are older than 18 months for that Linux distribution will be removed from the agent download. Update: This change is now scheduled for release October 22, 2018.
  • Talpa Binary Packs for kernel versions that are older than 18 months for that Linux distribution will be removed from the agent download.
  • Sophos will continue to provide Talpa Binary Packs for all kernel versions for supported Red Hat Enterprise Linux 6/7 distributions.

  • A definitive list of kernel versions for which Talpa Binary Packs are provided will continue to be published and updated on a regular basis. See TalpaBinaryPacks.txt for the current list. Note: this list is updated automatically when Talpa Binary Packs are added and removed.
  • Existing Sophos Anti-Virus for Linux installations will not be affected by this change. Talpa on-access scanning will continue to function without interruption and Sophos will continue to support customers using the product.
  • If on-access scanning is required and Sophos does not provide a pre-compiled Talpa Binary Pack for your kernel, the following options are available:

Related:

Sophos Anti-Virus for Linux: System requirements

This knowledge base article lists the system requirements of the Sophos Anti-Virus for Linux for Sophos Central, Sophos Enterprise Console and the standalone versions.

The following sections are covered:

Applies to the following Sophos products and versions

Sophos Anti-Virus for Linux

Sophos Anti-Virus for Linux 10

Sophos Anti-Virus for Linux 10 offers additional capabilities which include Malicious Traffic Detection and Sophos Security Heartbeat™ (applies to Central Server Protection license).

Here is the list of its minimum system requirements:

Sophos Anti-Virus for Linux 9

Sophos Anti-Virus for Linux 9 is the only version available for the standalone and Enterprise Console-managed versions.

Here is the list of its minimum system requirements:

  • Supported Distributions (latest minor point or LTS version):
    • Amazon Linux, Amazon Linux 2
    • CentOS 6/7
    • Debian 9, 10
    • Oracle Linux 6/7
    • Red Hat Enterprise 6/7/8
      • Red Hat Enterprise Linux 6 32-bit version supported until Nov 30th 2020
    • SUSE 12/15
    • Ubuntu 16/18 LTS
  • System type:x86_64
  • Free disk space: 1 GB
  • Free Memory: 1 GB
  • Stack sizes: Non-default stack sizes are not supported.
  • Language version: English and Japanese (EUC and UTF-8). Shift JIS and JIS are not supported.

If you’ve spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.

This is invaluable for us to ensure that we continually strive to give our customers the best information possible.

Related:

Sophos Anti-Virus for Linux: Additional steps required for SAV on Red Hat Enterprise Linux 8

This article provides the additional steps required to install and run Sophos Anti-Virus for Linux on Red Hat Enterprise Linux 8. For both Central and SEC managed environments

Applies to the following Sophos products and versions

Sophos Anti-Virus for Linux

Operating systems

Red Hat Enterprise Linux 8

With the release of Red Hat Enterprise Linux 8, a number of new and tighter security features have been introduced and these have meant some additional steps are required to install and run SAV for Linux.

  1. Set a variable to refer to the SAV install point.

    # INST=/opt/sophos-av

  2. Create a context to label all files in $INST/talpa with the ‘is-kernel-module’ label.



    # semanage fcontext -a -t modules_object_t "$INST/talpa(/.*)?

  3. Set the SELinux Boolean to allow all root processes to load kernel modules. [see note 1]

    # semanage boolean --modify --on domain_kernel_load_modules

  4. Install libnsl for UNC updating to work on SEC managed environments. [see note 2]

    # yum install -y libnsl

  5. Install SAV without starting savd.

    # ./install.sh $INST --autostart=False

  6. Apply the correct labels to $INST/talpa. [see note 3]

    # restorecon -R -v $INST/talpa

  7. Start savd.

# systemctl restart sav-protect

Additional Notes:

  • SAV for Linux requires the ability to load modules to kernel. This is disabled by default in SELinux. The SELinux Boolean option will allow all root processes to load kernel modules. By default SELinux on Red Hat Enterprise Linux 8 prevents daemons from loading kernel modules.

  • The libnsl step is only needed where SAV version 9 is updating via UNC cifs/windows share location.

  • The restorecon command is for restoring SELinux Context of the directory and will need to be done every time SAV is re-installed.
  • If on-access is required with Talpa the for on-access scanning, the following packagers are required

# yum install kernel-devel

# yum group install “development Tools”

# yum install elfutils-libelf-deveplease

Please see compiling Talpa for further details

If you’ve spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.

This is invaluable for us to ensure that we continually strive to give our customers the best information possible.

Related: