10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access

Gleb Smirnoff glebius at FreeBSD.org
Thu Jan 9 10:42:26 UTC 2014


  Guy,

On Sat, Jan 04, 2014 at 03:06:02PM +0200, Guy Yur wrote:
G> I am running 10.0-RC1 arm.armv6 on the BeagleBone Black.
G> The "pfctl -s state" command is crashing when trying to print the
G> second entry.
G> 
G> struct pfsync_state has a size that is not divisiable by 4 or 8 leading to the
G> second entry in the returned state array not being aligned and pfctl
G> core dumps on Bus error when trying to access a uint32_t field.
G> 
G> (gdb) bt
G> #0  print_host (addr=0x2085a11a, port=7660, af=2 '\002', opts=1024) at
G> /usr/src/sbin/pfctl/pf_print_state.c:178
G> #1  0x00021c4c in print_state (s=0x2085a0f2, opts=1024) at
G> /usr/src/sbin/pfctl/pf_print_state.c:236
G> #2  0x0000c664 in pfctl_show_states (dev=<value optimized out>,
G> iface=0x0, opts=1024) at /usr/src/sbin/pfctl/pfctl.c:1095
G> 
G> sizeof(struct pfsync_state_key) is 36
G> sizeof(struct pfsync_state_peer) is 32
G> sizeof(struct pf_addr) is 16
G> sizeof(struct pfsync_state) is 242
G> 
G> Removing the __spare[2] field will allow the struct to be aligned on 8 bytes
G> for the u_int64_t id field and also cover the uint32_t fields alignment
G> but this will break KBI.
G> 
G> I am currently using an inefficient workaround in pfctl_show_states
G> that memcpy each entry to a struct pfsync_state on the stack
G> ensuring each call to print_state receives an aligned struct.
G> 
G> 10.0-RC1 World and kernel were compiled in a VirtualBox VM running
G> 9.2-RELEASE-p2 i386.
G> clang and ARM_EABI used as the default make options.

For pf we are ready to break KBI. It uses same structs for internal kernel
representation and for ioctl() API and this is actually a bug. Until it is
properly fixed, we are doomed to break KBI always.

Unfortunately, pfsync_state is not only a KBI but also a wire protocol for
pfsync(4). We can't break this, since that would make different FreeBSD
versions not exchanging states properly.

Well, <= 8.x already is incompatible with >= 9.x, thanks yet another OpenBSD
import. But we don't want to introduce another one.

I will try to fix this making new structure for the ioctl. That will mean
moving slowly towards divorcing internal structures and ioctl ones.

I'd appreciate if you file a PR on that, so that problem won't leave forgotten
in the mailing list. You can even code the bugfix :)

Thanks!

-- 
Totus tuus, Glebius.


More information about the freebsd-net mailing list