Suricata stopped working on 2.5.0-DEVELOPMENT (amd64) built on Sat Jun 01 20:37:20 EDT 2019

jjstecchino

Suricata exited on signal 4 (core dumped)

Don't know if important but hyperscan was installed/updated in this release where suricate stopped working. Suricata was working fine before update

jjstecchino

Is it seems hyperscan requires at least SSE3 but my Atom C2758 only support SSE2. Is there a way to disable hyperscan on suricata?

jjstecchino

My bad this Atom actually support SSE3 so that shouldn't be it

bmeeks

Hmm...that error is caused by the binary code attempting to execute an illegal instruction.

A change was made to the Hyperscan port used in pfSense late last week. The change toggled on a parameter that supposedly lets Hyperscan use native encryption instructions when it detects the capability on the hardware. Otherwise it is supposed to downgrade to emulating them in software. Perhaps that is not working as intended and Hyperscan is actually trying to use instructions that are not present on some CPUs.

I will see about testing this in a virtual machine today.

bmeeks

@jjstecchino:

The change made last last week to the build options for the Hyperscan library is the likely culprit. That change is being reverted and a new Hyperscan library will be built.

A new Suricata version for pfSense-2.5-DEVEL should appear shortly. The new version will have the fixed Hyperscan library.

The Rest of the Story:
The change to Hyperscan was suggested by a Suricata user. What the change supposedly does is allow Hyperscan to detect when certain newer high performance encryption instructions are native in hardware and use them instead of the older ones. Sounded good on paper, but the devil is always in the details ... . As this thread shows, what actually happens is that detection of the newer native instruction codes occurs on the build host where the Hyperscan package is built and not at runtime on the target host when the library code is executed. So since the pfSense builder is a highly-capable Intel server, the Hyperscan code detected the new instructions during the build process and falsely assumed they would always be present at runtime. Obviously that's not the case when you run the resulting library on an Atom machine or any platform lacking the new encryption instructions.

jjstecchino

@bmeeks

Yup, the devil is always in the details.
It would be nice, though, to be able to build hyperscan on the local host, optimized for the local processor, but I guess the package manager can just install packages and not build from port, right?

bmeeks

@jjstecchino said in Suricata stopped working on 2.5.0-DEVELOPMENT (amd64) built on Sat Jun 01 20:37:20 EDT 2019:

@bmeeks

Yup, the devil is always in the details.
It would be nice, though, to be able to build hyperscan on the local host, optimized for the local processor, but I guess the package manager can just install packages and not build from port, right?

Unfortunately pkg is only designed to install precompiled binaries. pfSense also uses it to install PHP files, but really to pkg they all just appear as a collection of files to install in specified directories.

You would not want the baggage and potential security exposure of having a full build system complete with compilers and all sorts of supporting libraries on your firewall.

jimp

@bmeeks said in Suricata stopped working on 2.5.0-DEVELOPMENT (amd64) built on Sat Jun 01 20:37:20 EDT 2019:

Unfortunately pkg is only designed to install precompiled binaries. pfSense also uses it to install PHP files, but really to pkg they all just appear as a collection of files to install in specified directories.

I haven't looked to see if it's supported, and I doubt it is, but FreeBSD packages can now have "flavors" which specify different sets of compile-time options. There could be two flavors of the port with optimizations on or off (or for each type of supported optimization), and then different meta-ports which pull in specific combinations of flavors. It would be difficult to keep things setup with proper dependencies and also support multiple flavors in that way, but technically possible.

bmeeks

@jimp said in Suricata stopped working on 2.5.0-DEVELOPMENT (amd64) built on Sat Jun 01 20:37:20 EDT 2019:

@bmeeks said in Suricata stopped working on 2.5.0-DEVELOPMENT (amd64) built on Sat Jun 01 20:37:20 EDT 2019:

Unfortunately pkg is only designed to install precompiled binaries. pfSense also uses it to install PHP files, but really to pkg they all just appear as a collection of files to install in specified directories.

I haven't looked to see if it's supported, and I doubt it is, but FreeBSD packages can now have "flavors" which specify different sets of compile-time options. There could be two flavors of the port with optimizations on or off (or for each type of supported optimization), and then different meta-ports which pull in specific combinations of flavors. It would be difficult to keep things setup with proper dependencies and also support multiple flavors in that way, but technically possible.

That does sound interesting. I agree it sounds like a lot of coordination work to keep things straight. So does the user still have to choose the correct package from something like a list, or can pkg make a choice at install time?

jimp

@bmeeks said in Suricata stopped working on 2.5.0-DEVELOPMENT (amd64) built on Sat Jun 01 20:37:20 EDT 2019:

That does sound interesting. I agree it sounds like a lot of coordination work to keep things straight. So does the user still have to choose the correct package from something like a list, or can pkg make a choice at install time?

If the package has a dependency set, it would have to depend on a specific flavor, so you'd have, say packagename@option1 for the package name with option1 enabled, and packagename@option2 for the package with option 2 enabled. What typically happens is then you'd have meta-ports for either one with slightly different names, and unique dependencies, and the user would choose one to install.

Another way would be to remove a specific dependency from the port and have the installer pick which flavor to install but since that breaks dependency tracking I wouldn't want to encourage that.