Regression #13958
closed
Snort exits with signal 10 on arm32
0%
Description
In 23.01 Snort core dumps with signal 10:
Feb 15 21:48:21 php 56664 [Snort] Snort START for LAN(mvneta1)... Feb 15 21:50:56 kernel mvneta1: promiscuous mode enabled Feb 15 22:04:51 sshd 3863 Accepted keyboard-interactive/pam for admin from 172.21.16.8 port 47908 ssh2 Feb 15 22:05:00 kernel pid 2097 (snort), jid 0, uid 0: exited on signal 10 (core dumped) Feb 15 22:05:00 kernel mvneta1: promiscuous mode disabled
See: https://redmine.pfsense.org/issues/12157
Tested:
23.01-RELEASE (arm) built on Fri Feb 10 20:06:58 UTC 2023 FreeBSD 14.0-CURRENT
Updated by Bill Meeks 4 months ago
Signal 10 is the "unaligned memory access" fault. My first suspicion is an update of the llvm compiler in 23.01 has rendered the former workaround for 32-bit hardware ineffective. Changes were applied to the Makefile by one of the Netgate developers to force llvm to not fully optimize the Snort code during compilation and avoid the use of the single pair of armv7 opcodes that do not perform auto-fixup on unaligned accesses.
Snort binary code is notorious for having many places where unaligned memory access can occur (trying to read or write on non-word aligned memory address boundaries). The problem is unique to the 32-bit ARM chip used in the SG-3100 as that chip family has a single pair of opcodes that cannot do "auto-fixup" of non-aligned memory access at runtime. Unfortunately, the llvm compiler loves to use this pair of opcodes when optimizing armv7 executable code. Turning on DEBUG in the Makefile suppresses optimization and works around the bug, but also produces a more bloated and slower executable. Some time back, a Netgate developer dug deeper into the problem and added some additional options to the Makefile that altered the behavior of the llvm compiler. Those llvm options probably need to be revisited to see why they stopped working in 23.01.
This is the original fix added to the Makefile for the Snort binary:
# Disable SIMD on 32-bit arm. Snort has numerous arbitrarily misaligned memory
# accesses and some of them cause faults. The kludge below combined with
# patch-configure seems to work around it well enough.
#
# Note the change is more aggressive than it possibly needs to be reduce surprises.
CFLAGS_armv6= -mfpu=vfpv3
CFLAGS_armv7= -mfpu=vfpv3
If this same addition exists in the current Makefile for the ARM package branch, then for some reason the workaround has become ineffective with the update to FreeBSD-14 CURRENT.
Updated by Mateusz Guzik 2 months ago
Hi Bill, that was me.
What changed is that there was a compiler update and then it turned out some of the files don't get the flag(!), despite getting -O0 from noopt build.
Thus I patched configure itself to append the above and now it works again, I'll be posting a review soon.
Updated by Bill Meeks 2 months ago
Mateusz Guzik wrote in #note-2:
Hi Bill, that was me.
What changed is that there was a compiler update and then it turned out some of the files don't get the flag(!), despite getting -O0 from noopt build.
Thus I patched configure itself to append the above and now it works again, I'll be posting a review soon.
Thanks!
Updated by Christian McDonald about 1 month ago
- Status changed from New to Feedback
- Assignee set to Christian McDonald
- Plus Target Version changed from 23.01 to 23.05
patches for armv7 are now in our tree.
Updated by Steve Wheeler about 1 month ago
- Status changed from Feedback to Resolved
This looks good in current snaps:
pfSense-23.05.b.20230503.0600
pfSense-pkg-snort-4.1.6_7
snort-2.9.20_3