pfSense » pfSense Packages

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.

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.

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!