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

[Bill - Google Account via Snort-devel <snort-devel () lists snort org>]

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

 

_______________________________________________
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!