Project

General

Profile

Actions

Feature #2010

closed

Suricata should confirm SSSE3 presence at runtime when built with Hyperscan support

Added by Sascha Steinbiss over 4 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Target version:
Effort:
Difficulty:
Label:

Description

Dear Suricata team,

I noticed that the recently released Hyperscan 4.4 [1] introduces a new API function hs_valid_platform() to check whether the host provides the SSSE3 instruction set required by Hyperscan. With this in mind it would be nice if Suricata -- when compiled with HS support -- could check at runtime whether Hyperscan can be used, and fall back to the classic BM/AC matchers if not. This would, for instance, make life easier for downstream packagers, who would no longer need to distribute an additional non-Hyperscan-enabled binary for users without SSSE3. Indeed that is what we are currently doing in Debian.

I have started working on a proof-of-concept patch for Suricata to disable HS support at runtime when Suricata was built against Hyperscan 4.4 and SSSE3 support is not detected. The behaviour on earlier Hyperscan versions and builds without Hyperscan support should be unaffected. The code has been tested on amd64 systems with and without SSSE3 (the latter within a QEMU VM with -cpu qemu64,-ssse3 set), and I can confirm that the patched version builds, starts up and stays up with the default ruleset and also emits the expected debug messages.

I'd be happy to receive comments on the code in my feature branch in Git [2]. I tried to keep my changes as minimal as possible.

Many thanks and best regards
Sascha

[1] https://github.com/01org/hyperscan/releases/tag/v4.4.0
[2] https://github.com/inliniac/suricata/compare/master...satta:hs_valid_platform

Actions #1

Updated by Victor Julien over 4 years ago

Hi Sascha, quickly glancing over the code I think your approach makes sense. Could you do a pull request as described here? https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Contributing Thanks!

Actions #2

Updated by Sascha Steinbiss over 4 years ago

Victor Julien wrote:

Could you do a pull request as described here? https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Contributing

[x] Done. https://github.com/inliniac/suricata/pull/2517

Thanks for taking a look.

Actions #3

Updated by Peter Manev over 4 years ago

Wondering if anyone knows where could this (SSSE3 support) be reliably checked prior to buying a CPU for example?

lscpu - will output the (ssse3) info availability as well ... but just asking -

Flags:  fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat pln pts

Actions #4

Updated by Sascha Steinbiss over 4 years ago

Peter Manev wrote:

Wondering if anyone knows where could this (SSSE3 support) be reliably checked prior to buying a CPU for example?

AFAIK all newer Intel CPUs (IIRC since Core2 in 2006, Atom, Celeron, ... and some AMD) should support SSSE3, correct me if I'm wrong...
To check for SSSE3 support during building, the Hyperscan devs build a small piece of code using one of the SSSE3-specific intrinsics: https://github.com/01org/hyperscan/blob/master/cmake/arch.cmake -- but if you go this way you obviously already have bought the CPU ;)

Actions #5

Updated by Victor Julien over 4 years ago

  • Status changed from New to Assigned
  • Assignee set to Sascha Steinbiss
  • Target version set to 3.2.1
Actions #6

Updated by Victor Julien over 4 years ago

  • Status changed from Assigned to Closed
Actions

Also available in: Atom PDF