[prev in list] [next in list] [prev in thread] [next in thread]
List: snort-devel
Subject: [Snort-devel] Unaligned access to packed structure compiler warning in Snort 2.9.x
From: Bill - Google Account via Snort-devel <snort-devel () lists ! snort ! org>
Date: 2019-05-29 19:51:40
Message-ID: 008301d51657$efc83960$cf58ac20$ () gmail ! com
[Download RAW message or body]
This is a multipart message in MIME format.
[Attachment #2 (multipart/alternative)]
This is a multipart message in MIME format.
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
[Attachment #5 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type \
content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 \
(filtered medium)"><style><!-- /* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Lucida Console";
panose-1:2 11 6 9 4 5 4 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" \
vlink="#954F72"><div class=WordSection1><p class=MsoNormal>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:<o:p></o:p></p><p \
class=MsoNormal><o:p> </o:p></p><p class=MsoNormal \
style='text-autospace:none'><span style='font-size:10.0pt;font-family:"Lucida \
Console";color:black'>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]<o:p></o:p></span></p><p class=MsoNormal \
style='text-autospace:none'><span style='font-size:10.0pt;font-family:"Lucida \
Console";color:black'> return _sfip_pton(src, &dst->addr, \
&dst->bits);<o:p></o:p></span></p><p class=MsoNormal \
style='text-autospace:none'><span style='font-size:10.0pt;font-family:"Lucida \
Console";color:black'> &nbs \
p; \
\
^~~~~~~~~<o:p></o:p></span></p><p class=MsoNormal>The <span \
style='font-size:10.0pt;font-family:"Lucida Console";color:black'>sfcidr_t</span> \
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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p \
class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p \
class=MsoNormal>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 _<i>sfip</i>_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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p \
class=MsoNormal>Should not this function or the underlying structure variables be \
rewritten to avoid the potential of unaligned memory access in the first place? \
<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b><i><span \
style='font-size:12.0pt;color:#1F497D'>Bill Meeks<o:p></o:p></span></i></b></p><p \
class=MsoNormal><b><i><span style='font-size:10.0pt;color:#1F497D'>Vidalia, GA \
USA</span></i></b><o:p></o:p></p><p \
class=MsoNormal><o:p> </o:p></p></div></body></html>
_______________________________________________
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!
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic