BPF JIT compiler
The existing intel BPF JIT compiler has one flaw. sys/net/bpf_filter.c
initialises the A and X registers to zero when called. The just in time
compiler does not. This means the JIT compiler will behave differently
to the interpreter on any filter that does not set the A or X registers
before using them.
One approach is to put two additional ops in the procedure header of all
compiled filters to zero these registers. This is the easiest thing to
do, though it does mean a slower JIT compiler. Another approach is to
reject any filter that might use A or X before setting it. This
approach is really no different to having code check the filter and
conditionally include zero operations if necessary.
Below is a recursive function to check if A or X need to be set in the
procedure header. This function would go in bpf_jitter.c and set two
additional struct members in bpf_jit_filter to allow the machdep code to
do the right thing.
To my way of thinking, the bpf_insn_seta, bpf_insn_usea, bpf_insn_setx,
bpf_insn_seta functions could perhaps be macros. Of greater concern to
me is any policy that may exist on recursion in the kernel.
Comments, please. jkim@ is busy with other things, so if you're
interested, please speak up.
static int bpf_insn_seta(const struct bpf_insn *ins)
{
if(BPF_CLASS(ins->code) == BPF_LD || ins->code == (BPF_MISC|BPF_TXA))
{
return 1;
}
return 0;
}
static int bpf_insn_usea(const struct bpf_insn *ins)
{
if(BPF_CLASS(ins->code) == BPF_ALU ||
(BPF_CLASS(ins->code) == BPF_JMP && BPF_OP(ins->code) != BPF_JA) ||
ins->code == (BPF_RET|BPF_A) ||
ins->code == (BPF_ST) ||
ins->code == (BPF_MISC|BPF_TAX))
{
return 1;
}
return 0;
}
static int bpf_insn_setx(const struct bpf_insn *ins)
{
if(BPF_CLASS(ins->code) == BPF_LDX || ins->code == (BPF_MISC|BPF_TAX))
{
return 1;
}
return 0;
}
static int bpf_insn_usex(const struct bpf_insn *ins)
{
if((BPF_CLASS(ins->code) == BPF_ALU && BPF_SRC(ins->code) == BPF_X) ||
(BPF_CLASS(ins->code) == BPF_LD && BPF_MODE(ins->code) == BPF_IND) ||
(BPF_CLASS(ins->code) == BPF_JMP && BPF_SRC(ins->code) == BPF_X) ||
ins->code == (BPF_STX) ||
ins->code == (BPF_MISC|BPF_TXA))
{
return 1;
}
return 0;
}
/*
* bpf_ax
*
* determine if we need to initialise the accumulator and index
* registers.
*/
static void bpf_ax(const struct bpf_insn *fp, int i, int nins, int *a,
int *x)
{
const struct bpf_insn *ins;
int a1, a2, x1, x2;
while(icode) == BPF_JMP)
{
if(BPF_OP(ins->code) == BPF_JA)
{
bpf_ax(fp, i+1+ins->k, nins, a, x);
}
else
{
a1 = a2 = *a;
x1 = x2 = *x;
bpf_ax(fp, i+1+ins->jt, nins, &a1, &x1);
bpf_ax(fp, i+1+ins->jf, nins, &a2, &x2);
if(a1 == 1 || a2 == 1)
*a = 1;
else
*a = 0;
if(x1 == 1 || x2 == 1)
*x = 1;
else
*x = 0;
}
break;
}
i++;
}
if(*a != 1)
*a = 0;
if(*x != 1)
*x = 0;
return;
}
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP options order changed in FreeBSD 7, incompatible with some routers
Hi, On Wed, Apr 09, 2008 at 08:23:13AM +, Bjoern A. Zeeb wrote: >> I had the same problem, and temporarily worked around it by disabling >> SACK: > ok, here we go... > > as I had explained on freebsd-net@ lately there had been 2 changes to > possibly fix this issue. > > I am currently in the process to find out which of the two is actually > needed and which of the two prior versions caused the problems. > > I have a testbed setup and will have it running for another day or so. > > So could you try to reproduce your problems with the following three > servers (if you could ask your affected customers to test and > report back to you that would be highly appreciated as well). I just got access to a remote PC which has the problem, finally. It runs Windows 2000, service pack 4. > Simply open the following URLs in a browser is enough. If you can > see the pages, fine. If you cannot, tell me which worked, which > didn't. > > http://tcptest1.sbone.de/ This URL does not work, I get "siden kan ikke vises" (page can not be displayed in Norwegian). > http://tcptest2.sbone.de/ This URL works fine, I get the FreeBSD 7.0 TCP options test page. > http://tcptest3.sbone.de/ This URL does not work, I get "siden kan ikke vises" (page can not be displayed in Norwegian). > I have a tcpdump running on my side so all connections will be fully > logged. Good. Your patch on http://sources.zabbadoz.net/freebsd/patchset/20080309-01-tcp-options-padding.diff fixes the problem for me, with SACK still being on as it is by default. I would be much happy if this fix could find it's way to RELENG_7_0 and errata. Thanks a lot! Cheers, -- Anders. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP options order changed in FreeBSD 7, incompatible with some routers
On Fri, 11 Apr 2008, Anders Nordby wrote: Hi, in case you did not receive a private mail from me please do not go to any of the mentioned urls or you will make a one week data collection worthless. Thank you. PS: the webservers will go away within a few hours anyway... Simply open the following URLs in a browser is enough. If you can see the pages, fine. If you cannot, tell me which worked, which didn't. http://tcptest1.sbone.../ http://tcptest2.sbone.../ http://tcptest3.sbone.../ -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bpf does not see packets forwarded with ipfw fwd
Hi! One of 7.0 users has reported in some cyrillic newsgroup a problem that I have reproduced in my 7.0-STABLE system. That is: tcpdump does not show locally originated outgoing IP packets that were processed by 'ipfw fwd' rule. The same configuration presents no problems with 6.3-STABLE. Consider simple schema: two FreeBSD boxes (A and B) directly connected with ethernet intefaces. The box A has another ethernet interface and uses "ipfw fwd" as its very first ipfw rule to forward some packets to B, while these packets would normally go out trough mentioned another interface. Now, tcpdump does NOT show outgoing packets but host B also runs tcpdump on its incoming interface and does see them. I double-checked all paramerets for tcpdump, all routing tables. I even connected A and B with cross-over ethernet cable, without a switch. Still, B sees incoming packets coming over the cable and A does not see them leaving. This bothers me a bit :-) Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
