On Mon, 20 Aug 2018 23:38:28 +0900 (JST), YASUOKA Masahiko
<yasu...@openbsd.org> wrote:
> Hi,
Heyho.
> > panic: trap type 0x34 (mem address not aligned): pc=15864ec
> > npc=15864f0 pstate=99820006<PRIV,IE>
> (snip)
> > o...@eigenstate.org and I put together the following diff. I haven't been
> > able
> > to check with the original reporter, and I don't have a machine to test it
> > on,
> > so comments and/or tests would be appreciated!
>
> Do you have a test case of this?
You're responding to a request for a test case. The initial reporter
disappeared after providing a stack trace, so we couldn't confirm if this
makes a difference at all.
Right now, this is an untested stab in the dark. It would be unsurprising if
the fix is wrong.
> As far as I know, switch(4) assumes it receives packets located at 64
> bit aligned memory. So if the code like below
>
> *(uint64_t *)oxm->oxm_value = htobe64(val);
>
> cause alignment faults, the assumption may be broken. If so, the
> place we should fix may not be here.
The reason we are suspicious here is because oxm_value comes from struct
ofp_ox_match, which is defined like this:
struct ofp_ox_match {
uint16_t oxm_class;
uint8_t oxm_fh;
uint8_t oxm_length;
uint8_t oxm_value[0];
} __packed;
While the packet may be aligned to 8 bytes, my reading is that the oxm_value
itself is not at the start of the packet, and is not aligned within the
ofp_ox_match. I'm not familiar enough with the open flowz to know if
ofp_ox_match is guaranteed to start at a 4-byte alignment (which would
push oxm_value out to an 8 byte alignment), but I suspect that's not the
case.
--
Ori Bernstein
