It’s not marked as started. Disabling, enabling, reloading rulesets etc from the GUI has no effect.
Kernel log:
17:41:20 kernel: traps: Suricata-Main[6325] trap invalid opcode ip:7eae3125a2a0 sp:7ffe3aeba0b0 e rror:0 in libhs.so.5.4.11[7eae3121f000+94d000]
IPS (“Intrusion Prevention”) log:
|17:41:20|suricata: |This is Suricata version 7.0.6 RELEASE running in SYSTEM mode|
|17:41:20|suricata: |CPUs/cores online: 4|
|17:41:20|suricata: |master exception-policy set to: pass-packet|
Interesting. Mine is working in CU187 Testing without any problems.
I pressed the Save button in case that would make it stop but it stayed running.
I disabled the Intrusion Prevention and pressed Save and it stopped. I then enabled it and pressed Save again and it started back up.
I have the Emerging Threats and Abuse.ch Blacklists ruleset providers selected.
What do you see in the System Logs - Intrusion Prevention selected from the Dropdown box when you press the update button after having disabled the Intrusion Prevention and pressed Save and then enabling the Intrusion Prevention and pressing the Save button.
The libhs.so.5.4.11 is due to vectorscan.
vectorscan replaced hyperscan in this Testing release. Not sure why it would be causing a problem on your system and not on mine or on @ms system as he also tested it out earlier and didn’t have a problem.
Would be good to know if other users are or are not having any issues.
Are you using x86_64 or aarch64?
Yes, x86_64, an Atom 330 processor.
What I posted as “IPS log” in my first post. 
Sorry I took that to be the WUI menu Logs - IPS Logs.
So there is no message about stopping at all.
That suggests that the kernel message about trapping an invalid opcode related to the vectorscan library is causing suricata to just be immediately stopped without any time to log anything.
However I haven’t the faintest idea what could be causing that and can’t investigate on my systems as they are not experiencing the problem.
Further searching I have done has found a reference to someone having problems with suricata dying but with hyperscan.
That was linked to a particular rule that was causing a problem with the pattern matching processor in hyperscan.
Maybe something similar is happening here. You could try disabling the individual rules in the ruleset and see if at some stage suricata is then able to start.
The simplest option would be to only have the Abuse.ch Blacklist rule provider selected and then just select the single rule that is provided.
I just tried that on my system and it worked fine.
If your system still crashes with only that rule enabled that would eliminate a rule matching issue with vectorscan.
Ah, logical. No, nothing has been written in that log since the upgrade.
You read the pfSense megathread? Just read that myself. No, this has no effect, I had already tried it but now I tried it again.
Just a hunch: vectorscan was originally developed for non-Intel architectures. Perhaps support for more obscure Intel processor models isn’t that hot? Or some vector instructions that doesn’t exist on Atom are needed/are enabled on compile? AVX isn’t available on Atom.
I did wonder about that myself and did a search on the vectorscan issues page but couldn’t find any reference to a similar issue with an older processor.
The vectorscan github site says
Vectorscan aims to be ABI and API compatible with the last open source version of Intel Hyperscan 5.4.
Not sure if that would mean that it should also work on Atom as Hyperscan did.
Maybe raise a bug for it, although it might also be good to be raised at vectorscan so they can comment about the Atom processor concern.
So the /etc/suricata/suricata.yaml file has two settings in it which are set to auto. If hyperscan (or vectorscan) are present then the algorithm will be set to “hs” and if it is not present then mpm-algo will use “ac” and spm-algo will use “bm”.
You could try editing the suricata.yaml file and changing mpm-algo to ac and spm-algo to bm and then seeing if suricata works. It would then be working without vectorscan and if it then works it would confirm that vectorscan is the problem and probably doesn’t like something about your system.
Still worth raising a bug as suricata.yaml would likely get replaced in any update that included suricata changes.
Sadly, that didn’t work. The Intrusion Prevention log produced another line:
HTTP memcap: 268435456
Kernel log gave the same error.
That’s interesting. That means that vectorscan itself, completely separate from being used by suricata is causing suricata to crash.
I am afraid I have currently run out of ideas.
I would raise a bug on this, to get it recorded.
Hello,
It looks like vectorscan is always at least requiring SSE4.2. So we have some instructions in there that are not understood by the Atom 330 as it is too old.
This might potentially create a packaging dilemma for us, but I can’t investigate this right now as I am away from my desk.
We might also want to consider dropping support for ancient hardware if we don’t get the support for this from upstream.
Michael,
According to Fireinfo, SSE4.2 is supported on 78.57% of x86_64 IPFire installations. Given this, it might make sense to consider dropping support for older hardware in the near future. Targeting x86-64-v2 could be a practical approach.
Additionally, supporting < x86-64-v2 will be increasingly problematic. Many older CPUs don’t get microcode updates anymore, so we’re relying on kernel mitigations for vulnerabilities like Spectre and Meltdown etc. Some of these mitigations come with performance hits, on top of the already limited performance of older hardware.
And of course, not having to worry about older CPUs would likely simplify maintenance of the project.
Looking ahead, it would be exciting to see targeted builds for x86-64-v3 and x86-64-v4 as well.
Best,
A G
This is already a sealed plan for IPFire 3 which we only compile like this.
That is a whole huge sack of worms to open… In this particular case, the Intel Atom 330 is not affected by anything as it does not have speculative execution. But I would absolutely agree with the statement that if a vendor doesn’t support the CPU any more, it might be unsafe to keep using it.
That would (and the section from above) create a lot of e-waste which could be avoided if vendors had sensible support times and looked less after profit, and it maintainers had a lot more time on their hands to support older things too. I believe that we mostly make these decisions because of a shortage of resources, not because it is only technically a good decision.
This would make a lot of hardware not eligible for IPFire and I am not really sure what the gains would be. I don’t think it is a lot as the code that is being frequented a lot is already heavily optimised and uses modern CPU extensions; and the code that isn’t frequented often does not need to be optimised because CPUs are very fast.
I was once looking for benchmarks about this, but could not find anything to prove or disprove my assumption.
This is big news. Glad to hear it though.
Sorry 
Fair enough. I don’t know that specific model.
This is the difficult part, right?. With IPFire playing a security-critical role, should the project support a device for longer than the hardware manufacturer does? I would say yes, but the security/performance implications should be made clear to the user, which it already does to some extent with the Hardware Vulnerability section in the WUI.
I agree. Unfortunately, it looks like hardware support will continue to be an issue until we have more competitive open-source hardware. But that’s another matter.
I was actually thinking of separate builds/packages for x86-64-v2, x86-64-v3, and x86-64-v4. I’m not sure if the core of IPFire would benefit from it much, but IPFire’s add-ins might. Remember, IPFire is More Than A Firewall
To be fair, I have compiled IPFire to target my specific firewall hardware in the past by adding -march=alderlake specific flags. It built without issues, but I didn’t notice any performance boosts in my small network setup. However, if this was scaled up to big business levels of traffic, with IPS, block lists, lots of complex rules, and QoS, wouldn’t it be of benefit there?
Do you know anyone who has a heavy level of IPFire use, running a complex setup, and would be willing to have a small amount of downtime to test on their x86-64-v3/v4 system? 
Best,
A G
@mangrove Could you confirm that you have the latest version of the update installed? It is in the signature of the web UI.
Vectorscan requires SSE4.2 and cannot be compiled without it. However, it should not crash by trying to execute illegal instructions. There is a check function that suricata calls and if the function says that Vectorscan is not supporting the CPU, it will fall back to internal options:
If I run the latest version on a VM without SSE4.2 I am getting the following message in the Suricata log:
SSSE3 support not detected, disabling Hyperscan for SPM
It should say SSE4.2 here, but Hyperscan only required SSSE3.
So I believe there is nothing left to be done. The problem has been fixed:
git.ipfire.org Git - ipfire-2.x.git/commitdiff
No need to apologise. I love having this discussions…
I think this is a very strong point. However, that would bin a lot of good hardware. And looking at the market, there isn’t that much good stuff out there. So I think it is not very practical.
We should rather have (maybe through legislation) the vendors support hardware for longer. Some hardware is being released and EOL on the same day. That is nothing that we can fix on the software side.
As usual, Phoronix delivers:
Looking at the OpenSSL benchmark on this one, there is practically no difference there. And that makes a lot of sense. Glibc for example has lots of versions of certain functions and uses the best one for the CPU. The kernel does the same with cryptography and so does OpenSSL.
That being said, where performance matters for us, we are already using the best as possible. Since all the optimisations for graphics and other CPU-bound tasks are not too relevant for us, I would say this helps us to make the decisions to stay with -v2 for IPFire 3 and with plain old x86_64 on IPFire 2. It isn’t worth producing the e-waste.
No, interrupt handling, congested CPU caches are the bigger bottlenecks here. Usually on the firewall the CPU is very idle and does not do much “computing”. The biggest exception for that is Suricata which has Vectorscan to make use of the CPU extensions.
Probably, but looking at the benchmarks, I don’t think you would be able to measure any difference.
My version is master/5b58a169
Yeah, that is the older build without the fat library which confirms my previous statement:
I can confirm that this is now working again in 188 Testing.