Re: Unaligned access to packed structure compiler warning in Snort 2.9.x

["Michael Altizer \(mialtize\) via Snort-devel" <snort-devel () lists snort org>]

On 5/29/19 3:51 PM, Bill - Google Account via Snort-devel wrote:
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?

Bill Meeks
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.

_______________________________________________
Snort-devel mailing list
Snort-devel () lists snort org
https://lists.snort.org/mailman/listinfo/snort-devel

Please visit http://blog.snort.org for the latest news about Snort!