[prev in list] [next in list] [prev in thread] [next in thread] 

List:       snort-devel
Subject:    RE: [Snort-devel] Bus error with Snort-2.0.6/spo_database.c on Sparc.
From:       "Jim Cervantes" <jcervant () umbranetworks ! com>
Date:       2003-12-30 15:29:03
Message-ID: ILEOJAPLJKJKCBEMPELNMEMMCKAA.jcervant () umbranetworks ! com
[Download RAW message or body]

Paul,

My guess is that the problem stems from captured packets (from libpcap)
being 32-bit (longword) aligned (at least some of the time, if not all of
the time).  After stripping off a 14 byte ethernet header, you end up with a
16-bit (word) aligned packet.  This results in word aligned ip and tcp
headers in the Packet decode structure.  This all smells like snort hasn't
been built in a fashion compatible with your machine architecture, although
it may merely reflect a problem with spo_database.c.

On the other hand, in some sense the error can be attributed to decode.c, in
DecodeIP:

p->iph = (IPHdr *) pkt;

This statement "manually" creates the pointer p->iph from a cast of a byte
pointer and is what violates the alignment restrictions of your
architecture.

As to changing the struct definitions, I think that won't help.  The current
definitions are intended to be "packet templates" and if you add your own
padding to them they will no longer conform to the underlying packet
structure.

I think your best bet here is to solicit comment from the relevant
implementors about the overall philosophy and implementation of packet
parsing, packet templating and access methods.

Jim


-----Original Message-----
From: snort-devel-admin@lists.sourceforge.net
[mailto:snort-devel-admin@lists.sourceforge.net]On Behalf Of Paul van
Empelen
Sent: Tuesday, December 30, 2003 5:33 AM
To: snort-devel@lists.sourceforge.net
Subject: Re: [Snort-devel] Bus error with Snort-2.0.6/spo_database.c on
Sparc.


On Mon, Dec 29, 2003 at 05:56:46PM -0500, Jason Wever wrote:
> "Jim Cervantes" <jcervant@umbranetworks.com> wrote:
>
> > Addresses that generate bus errors when dereferenced are often
> > attributable to alignment problems.  The underlying machine instruction
> > set may have restrictions on how words of certain sizes are accessed.
> > Looking at your debugging printf's below, it looks like you bus error'ed
> > trying to read p->tcph->th_seq.  That's a 32-bit (long word) quantity.
> > According to your debugging output, it's aligned to a 16-bit (word)
> > boundary (0x24782e).  This may explain the problem.  Usually these sorts
> > of issues are handled relatively transparently by C compilers as padding
> > is added to struct memory layouts to maintain alignment restrictions,
> > but there are various ways that things can go astray - for instance
> > custom memory management or certain build problems.  Hope this helps.
>
> I've been seeing this across the whole 2.0.x series using Linux on sparc.
> Not sure if this happened pre-2.0.x or not.
>
> Does snort work reliably on other big endian arches?
>
> Also, Paul, what did you use to build snort?

Hi Jim, Jason,

Thank you for your replies.  It is really helpful.  I understand the issue
now.

Initially, I compiled it with gcc 3.2 (make 3.80).
Today, I upgraded to the latest & greatest gcc:
> gcc -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3.2/specs
Configured with:
../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-n
ls
Thread model: posix
gcc version 3.3.2

Made a fresh install of snort-2.0.6/Spade, and inserted the printf's again:

address p->tcph->th_sport: 0x245a22
address p->tcph->th_dport: 0x245a24
address p->tcph->th_seq: 0x245a26
address p->tcph->th_ack: 0x245a2a
p->tcph->th_sport: 0x26648
p->tcph->th_dport: 0x1470
Bus error (core dumped)

Same issue here.  Again, 0x245a26 is not 32 bits aligned.

I found some TCP offset (alignment?) macro's in decode.h.  However, I
couldn't figure out the syntax.  Can I make an dirty workaround by
defining the 16 bit p->tcph->th_dport just after p->tcph->th_ack instead
of before p->tcph->th_seq?  Or is this a really bad idea...
Also, is there a document describing the internal data structures of snort
a bit more detailed than chapter 3 of the manual?

There is one thing I still don't get.  I am reading p->tcph->th_seq here.
Why isn't it complaining before, when writing to p->tcph->th_seq?  This
should be the same address, right?

Regards,

--Paul.



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Snort-devel mailing list
Snort-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-devel



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Snort-devel mailing list
Snort-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-devel
[prev in list] [next in list] [prev in thread] [next in thread]