For at least the last three Snort versions, when compiling in a pfSense builder environment (which is based on FreeBSD-12) using the llvm 6.0.1 compiler, the following warning is emitted multiple times during the build:
sf_ip.c:412:41: warning: taking address of packed member 'bits' of class or structure '_ip' may result in an unaligned pointer value [-Waddress-of-packed-member]
return _sfip_pton(src, &dst->addr, &dst->bits);
The sfcidr_t structure represented by the ‘dst’ parameter above is defined in the file <sfutil/sf_ip.h>. The structure is defined as packed. This means it will be byte-aligned. The structure member ‘bits’ is defined as a uint16_t. Thus in the function call above, ‘&dst->bits’ is assumed to be word-aligned (16-bit integer pointer). I think this is the ultimate caused of the error message described in the paragraph below.
pfSense images are available for both Intel-based AMD64 architectures and ARM v6/7 architectures, and on the ARM v6/7 images the Snort binary must be built with the DBGSNORT option enabled in order to avoid Signal 10 Bus Error faults at runtime. Signal 10 on FreeBSD indicates an unaligned memory access occurred. Using the DBGSNORT option turns off compiler optimizations. The llvm compiler, when not optimizing the resulting binary code, will choose to use some slower CPU opcodes that do support automatic fix-up of unaligned memory access. When compiling with optimizations, the compiler chooses to use different faster CPU opcodes, but unfortunately these instructions do not support automatic fix-up of unaligned access.
So during runtime, Snort will terminate with the Signal 10 Bus Error. I’ve been able to determine that the error occurs in the code of the _sfip_pton() function, and is due to the passed address of the ‘dst->bits’ parameter. Looking at the disassembled code in that area of the program, and comparing optimized (non-debug) code with the non-optimized (debug-enabled) code, I was able to determine that the Signal 10 error is a result of the instruction sequence chosen by the compiler. However, the actual root cause is the source code itself. It’s just that Intel-based machines will always automatically fix-up such unaligned access operations and silently proceed without error not generating a fault. Some non-Intel architectures do not behave the same way. They will instead issue a hardware interrupt on the unaligned access attempt, terminate the faulting application and log an error.
Should not this function or the underlying structure variables be rewritten to avoid the potential of unaligned memory access in the first place?
Vidalia, GA USA
Thanks for the report, Bill. It's been on my list for a long while (if for no other reason than to get rid of the compiler warning), but I hadn't been running on any architectures where it actually mattered. I'll try to bump it up a bit priority-wise.
I'll honestly be surprised if that's the only unaligned access we're performing, though; all the SPARC special-casing for similar issues didn't survive to make its way into Snort3. It might just be the only one the compiler can immediately notice since we
do cast packet data to various structures at fairly arbitrary offsets all over the place.