On Jun 15, 2005, at 1:42 PM, Daniel Hartmeier wrote:
On Mon, Jun 13, 2005 at 09:23:50PM +0000, Marcel Moolenaar wrote:
Synopsis: Unaligned Reference with pf on 5.4/IA64
Responsible-Changed-From-To: freebsd-net->freebsd-pf
Responsible-Changed-By: marcel
Responsible-Changed-When: Mon Jun 13 21:22:54 GMT 2005
Responsible-Changed-Why:
Move to a more pf-focussed responsible party.
http://www.freebsd.org/cgi/query-pr.cgi?pr=81284
If I understand the problem correctly, there is an underlying
network-generic question I'd like to ask here.
When a function in the kernel gets passed a struct ip pointer, can it
assume that the struct ip object pointed to is properly aligned? Or
should it assume that this is not the case, and extract members more
carefully?
That entirely depends. If a struct ip pointer is constructed without
any form of casting, then one can assume that alignment is guaranteed.
The compiler guarantees to do so, except of course in this case:
the structure is defined as a packed structure. We, as the developers,
have told the compiler to *NOT* guarantee alignment of fields. We're
on our own and we miserably fail being on our own.
We can fix the access in pf of course, but if other functions
rightfully
count on struct ip objects being properly aligned, this might simply
crash outside of pf, too.
True. But since struct ip is defined as packed, nobody can assume proper
alignment of multi-byte fields and all code needs to be fixed if such
assumptions are being made.
In short, is the problem that bridge doesn't properly align the struct
ip object (which I can try to fix, too), or that pf assumes that such
objects should be aligned?
pf(4) falsely assumes alignment.
If I'm way off, and proper alignment of struct ip objects does not
guarantee proper alignment of the ip_src/dst members as 32-bit
unsigneds, please explain.
You're not way off. It's just that we tried to outsmart ourselves by
telling the compiler that it should not enforce proper alignment of
fields in struct ip.
If ia64 is different from other 64-bit
architectures (of which I only know amd64, sparc64 and alpha), please
explain what alignment rules there are for u_int32_t.
ia64 is not different in this respect. That's why the bug is not
specific to ia64. Note that amd64 may not be a perfect reference
in this case because it's too much like i386, which does unaligned
loads and stores.
FYI,
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
